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.
12 Comments RSS · Twitter
Sounds painful. They probably should consider moving to Rails (http://www.rubyonrails.org/).
I don't think Rails would make any difference for the installation and usabiliity issues, and the permissions problems are due to the design of Subversion and BDB.
Reasonably seamless support for multiple projects is available if you use mod_python with Trac. Not to mention it'll run faster...
As a happy by-product of switching to Subversion 1.1's fsfs back-end, read-only processes no longer require write access to the repository. Trac promises never to write anything to the repository.
http://web.mit.edu/ghudson/info/fsfs
True, fsfs support and Subversion 1.1 are still technically unreleased, but after two BDB blowups in under a month and with Subversion's BDB pointpersons mystified by the rash of failures under OS X, 1.1.0rc2 it seems like a step up.
I just got the Subversion/Trac thing going at work and setup was definitely a pain although I really like the result.
You aren't by chance running them on Dreamhost are you? I'd love to figure out that setup (as painful as it might be).
Thanks,
Aaron
gentoo also has it packaged
emerge trac
definately takes some fiddling with apache and knowing where the files should go, but WELL WORTH IT, simple and powerful I LOVE IT
I have just started using Trac and found it fitted my requirements very closely. The only major gripe so far is I can't edit comments. IMHO this is a major flaw, especially for someone like me who only notices typos just after they have pressed the Submit button.
Ian.
[...] Naturally, when I switched from CVS to Subversion, I switched from CVSTrac to Trac. I like Trac even better than CVSTrac, except that it’s kind of a pain to install. When I got my iMac Core Duo I started thinking about building a universal binary version of Trac and realized that would be even more of a pain. [...]
I am migrating CVSTrac to Trac, still don't get how to migrate tickets/wiki to Trac.
Could you please paste more details?
