Archive for September 8, 2004

Wednesday, September 8, 2004 [Tweets] [Favorites]

Migrating to Trac

Having migrated from CVS to Subversion, the next step was to go from CVSTrac to Trac.

Trac was inspired by CVSTrac, and is similar to it in many ways, but there are also differences. CVSTrac tickets have Description and Remarks fields. When you edit one of these, the new version of the field replaces the old version, and CVSTrac saves the old version and displays it below. Trac has a single Description field, and you cannot edit it, only append new comments. Generally, this means you must read through more of the ticket history to figure out what needs to be done before the ticket can be closed. Some of the other fields don’t line up, either, but it was easy enough to use the sqlite tool to attach both databases and migrate all the ticket data that I cared about.

Installing Trac, while not difficult, is a pain. You have to build and install multiple Python packages and edit Apache’s config file to feed Trac some paths that it needs. Users and permissions are handled using an .htaccess file, which is fine, but for some reason I have to re-enter my login information between sessions. Support for multiple projects isn’t built-in, but requires more Apache rewrite rules. Likewise, where CVSTrac has a series of Setup pages in the browser, configuring similar options in Trac entails using the trac-admin command-line tool.

On the plus side, Trac has much nicer-looking Web pages. It colors code and displays diffs well, and it’s easy to tweak the fonts by editing the CSS files. The reports are more configurable.

I ran into two problems with Trac. First, in various places it doesn’t URL-encode the names of files in the repository. I have lots of files whose names contain #, and these weren’t accessible using Trac’s Subversion browser until I made some quick changes to Href.py.

Second, I kept getting errors where either (a) Trac didn’t have permission to access the repository, or (b) after using Trac, Subversion claimed that the repository was damaged. The problem was that I modify the local repository using the svn and svnadmin tools, running as user mjt. Trac accesses the repository through Apache, running as www. It seems that even reading from the repository requires write access, and new database log files in the repository weren’t being created with the proper permissions.

The solution was to use NetInfo Manager to create a new svn group, with mjt and www as members. (For some reason, I wasn’t able to use this group with chgrp until after restarting.) I assigned all the files in the repository to this group, and set the set-GID bit on the repository’s db folder. In addition, each process accessing the repository must have the proper umask. To make this happen, it was necessary to modify trac.cgi and use trampoline svn and svnadmin scripts. All this ensures that new database files in the repository get the proper ownership and permissions.

The Daily WTF

Ned Batchelder:

The Daily WTF is a snarky collection of those pearls of bad programming we all encounter from time to time. They’ve got one per day, covering a broad range of real-life abominations against the coding commandments.