Software Sorcery

I spent some time last night installing Trac (a project wiki/source viewing/issue tracking system) and Subversion, a version control system on my FreeBSD server. The process went pretty smoothly - once again, the pile o' praise I heap on the ports system continues to grow. I would still like more info when an options dialog pops up, so I can make better decisions, but besides that, it went like clockwork.

Personally, I'm a Perforce man when it coms to SCCS. I've been using it for years, and really feel like it is an excellent client/server system. The support has always been phenomenal and I've brought it along to several jobs since I first began using it. The biggest problem with Perforce is that it is incredibly expensive. It is a real "enterprise solution" and charges as such. It cost US$800 for each license! They do have a free evaluation, where you can create two users but only five clients (local views of the source tree), which is too limited for any kind of real usage. I used to have a single developer license for it, but I don't have that any more. They also have a free version for Open Source projects, but as I'm not sure where, if anywhere, we're going with our little project, it doesn't seem like it fits.

So the next option looks to be Subversion, an open source CVS replacement, that is also supported by Trac "out of the box". It was reasonably easy to set up, although getting it "locked down" was hard to figure out. I wish these things would be installed with no access and then force me to open them up, rather than the other way around. I do like the idea of the SSL that is built into svnserve, although it seemed complicated to set up, so I passed on that for now. It also occured to me that Subversion doesn't let you know when another developer is working on code, as you "check out" the entire source tree when you begin work and then just "commit" your changes to it. I like being able to see in Perfore when someone else has a file checked out, so I know if I should ask about it first, or just be sure to get my changes checked in quickly and force the other developer to deal with merges!-)

The devel/subversion-python port installed /usr/local/etc/rc.d/svnserve.sh, which is the spot where startup scripts are supposed to go, so always look there when you install a new server. For some reason, the test install on my PC-BSD called the file just 'svnserve'. Odd. Anyway, if you look in that file, it graciously tells you the options that need to be set in the /etc/rc.conf file in order for the server to run and to get going at start up. It says:

# Add the following line to /etc/rc.conf to enable SVNServe:
#
#  svnserve_enable="YES"
#  # optional
#  svnserve_flags="-d --listen-port=3690"
#  svnserve_data="/usr/local/repositories"
#  svnserve_user="svn"
#  svnserve_group="svn"

So I put my own values in there and started it up. I had to add "--listen-hostname=amazingdev.com" to the svnserve_flags line, as my machine hosts several domains and the connection didn't work at first. It must verify a hostname or something. I ran the svnadmin create command to initially set up the "repository" (I like Perforce's nomenclature of "depot" better - sounds less like an anal medicine:-), but it's off to the races!

Then I installed www/trac, which seems like a nice integrated web-based project site. It includes a wiki area, a way to browse syntactically colored source files in your Subversion repository, as well as bug tracking (it calls them "tickets"). It also keeps track of all changes and allows you to create milestones. Once again, the installation went smoothly, with a single prompt asking if I wanted to use Silvercity for syntax highlighting. Luckily, I had looked at the web site and noticed a caveat warning that Python highlighting doesn't work with the 0.9.6 version of Silvercity, which is what is currently in the ports. Seeing as textutils/enscript-letter works just as well, albeit perhaps slower but with more options, it doesn't seem like a big loss to not add it in, as I'm not sure you can get the 0.9.5 version recommended on the Trac website.

The one thing the port didn't do was to put a startup script for the builtin tracd server into the /usr/local/etc/rc.d folder, like the Subversion port did. Not sure why it didn't, as there isn't a real downside to putting one there, as it won't run until the admin modifies /etc/rc.conf. Maybe the port maintainer uses the Apache mod_python version of Trac? Anyway, using the svnserve.sh file as a model, I created my own tracd.sh file:

#!/bin/sh
#
# tracd.sh for rc.d usage (c) 2006 Jonathan Arnold
# $Id$

# PROVIDE: tracd
# REQUIRE: DAEMON
# BEFORE: LOGIN
# KEYWORD: shutdown
#
# Add the following line to /etc/rc.conf to enable Tracd:
#
#  tracd_enable="YES"
#  # optional
#  tracd_flags="-d --listen-port=3690"
#  tracd_data="/usr/local/path/to/project"

. "/etc/rc.subr"

# Set some defaults
tracd_enable=${tracd_enable:-"NO"}
tracd_flags=${tracd_flags:-"-d --port=8080 --pidfile=/var/run/tracd.pid "}
tracd_data=${tracd_data:-"/usr/local/trac"}
tracd_pidfile=${tracd_pidfile-"/var/run/tracd.pid"}

name="tracd"
rcvar=`set_rcvar`
load_rc_config $name
command=/usr/local/bin/tracd
command_args=" ${tracd_data}"
command_interpreter="/usr/local/bin/python"
pidfile="${tracd_pidfile}"

run_rc_command "$1"

I had to modify a few things from the svnserve.sh file. Most importantly, tracd is a python script, so you need to add the "command_interpreter" line, as the standard startup/shutdown commands look at the name of the process attached to the pid and if it doesn't match 'name', it won't kill it. But it will first check for 'command_interpreter' to check against. I also added the --pidfile option to the command arguments, so tracd would write out its PID to a standard place. And then tell the standard scripts where this is. But other than that, it was pretty easy and now I have a script to start up the builtin trac server by adding tracd_enable="YES" to my /etc/rc.conf file.