All types of content can easily be interlinked, as all parts interprete the common wiki link-style. For instance, “#123″ will be converted to a link to trouble ticket #123, and “r123″ or “[123]” will be converted to a link to the changeset (revision) 123 of the version control system. The same syntax is also interpreted for each commit entry or within the description of tickets, which provides a fast means of navigating to related ressources.

All information is displayed clearly in a timeline view. Changesets provide powerful and clear diff-views to show what has really been changed and the repository can be browsed for any given revision number. Any changeset can be downloaded as ZIP file, as unified diff or as individual files.

The trouble ticket system is not as powerful as Bugzilla‘s as it provides no distinction for multiple projects, but it is used more fluently and provides everything needed for a single project (regardless of size of the project).

A milestone view allows clear and easy planning of various releases and milestones and provides powerful progress measuring features.

We are currently using Trac for project management of our project. We had an existing Bugzilla database that had to be converted to Trac before we could use the tool. I used the script bugzilla2trac.py (rev. 3544, but check if there is a newer version). Our Bugzilla version was 2.20, the script officially only supports upto 2.19. Still, only one minor change was needed to get the import working with the 2.20 database scheme. At line 405, change the line to read

mysql_cur.execute("SELECT * FROM attachments a INNER JOIN attach_data ad ON ad.id=a.attach_id WHERE bug_id = %s" % bugid)

The import worked flawless, everything including attachments was imported, and (most importantly for being in-sync with our SVN commit-messages), the bug numbers where kept identical.

Trac at the moment only supports Subversion as version control system; they are working on integrating other VCs as well. Trac needs local access to the repository, as they access the repository directly, not via HTTP. It might however be possible to use a remote repository which is mounted locally using one of the many remote-fs available.

Trac natively uses SQLite as database backend for storing its data, official release also contains support for PostgreSQL and the current development version also works with MySQL. I am using the SQLite backend which caused litte problems:

Trac is written in Python, so for optimal performance it is best to use it with mod_python if you are using Apache. Be aware however, that if you also have mod_php (PHP 5) installed and mod_php/PHP is compiled with SQLite support, mod_python will not be able to read SQLite databases. A recompile of PHP without SQLite support solved the issue for me.

One last word about administration of Trac. Trac provides a powerful command-line util called trac-admin which gives you access to various settings. You use this tool for adding permissions to users, setting up components and managing severities for tickets. Most importantly, this tool also provides a means for backing up Trac: “trac-admin <repository> hotcopy <bak-dir>” will copy the current Trac environment to the backup location, while ensuring database transaction integrity.

One thing I want to mention here too is the fact that one installation of Trac can be used for several independent projects. For each project, a “Trac environment” is set up using trac-admin. The databases of the individual environments are independent, but they share the same codebase, so updating Trac updates it for every existing environment.

Concluding I want to say that Trac is definitely worth a try, you can even quick-test it by using its own webserver, so you do not have to set up Apache for use with Trac. This is however not recommended for production use.

Using Trac, project management, milestone planning, issue tracking, and documentation become fun.

In the present case, we have a Bugzilla database created with a charset of latin1. Unfortunately, now after updating MySQL to 4.1, error occured when trying to assign a new developer to a bug, indicating mismatch of collations (UTF-8 vs. Latin1). This is caused by the fact that there is now latin1-data stored in an UTF-8 table.

The following procedure can be used to upgrade the database to UTF-8, eliminating the problem:

1. mysqldump -p --default_character-set=latin1 --skip-set-charset bugs > dump.sql
2. mysql -p --execute="DROP DATABASE bugs; CREATE DATABASE bugs CHARACTER SET utf8 COLLATE utf8_general_ci;"
3. mysql -p --default-character-set=utf8 bugs < dump.sql
4. perl -pe 's/latin1_bin/utf8_general_ci/g; s/latin1/utf8/g' dump.sql > dump-utf8.sql
5. mysql -p --default-character-set=utf8 bugs < dump-utf8.sql

You should of course always check if the Pearl-RegEx only replaced charset declarations and not some matches within the data.

Thanks to TextSnippets for the script.

For integration of Bugzilla into the Active Directory, see this link (Update: Link is broken, for an archived version, use this link, thanks to the commenter!).