After nearly a decade of using Perforce for my private source control, I'd decided to switch to Mercurial. Mercurial is a distributed version control system and open-source and all kinds of awesome and I won't go into why I made the switch here. Suffice it to say it makes it much easier to release code and work with others. Mercurial itself is an easy installation and I had it running both on my OS X 10.4 and Windows XP in a flash. I even installed the newly released HgTortoise plugin, which works as advertised even though its user interface simply <i>screams</i> open-source. Now, Mercurial is nothing without a server, so I set about setting up one of those too. There's nothing like jumping in the deep end when you're a complete neophyte. I've got one project that I'd like to share publicly and a handful of private projects that I'd like to store on the server, but work on from several places (e.g. the Mac or Windows). Now, with Mercurial, every repository contains a complete history of the project, so the designation of the server as the "main" storage is a feature of my deployment system, not a requirement imposed by Mercurial<fn>. Mercurial has decent instructions for setting up an <c>http</c> server; they provide <c>CGI</c> scripts for both single and multiple repositories. Once you've got that, you'll want to set up which users are allowed to <i>push</i> updates to your repository. Mercurial strongly recommends you use only SSL connections for <c>push</c> operations; you can shut off the requirement easily enough, but it's a good recommendation. So far, no real problems have cropped up. Until you go to the web site and see the circa 1998-style horror that is the default style sheet. Running <c>hg -v</c> reveals that you're running version <c>0.9.1</c>, released in 2005. Thanks, Debian. Way to stay on top of things.<fn> A quick check of <a href="http://backports.org">Debian Backports</a> reveals that a newer version, <c>1.0.1.2</c> is available. Grab that and install it, then enable one of the newer themes---I chose <i>paper</i>, which looked nice and neat---and refresh the page. Sweet! Click a link. Shit! Purple python error messages everywhere. Follow the stack trace to the bottom of the page and it seems to be complaining about an unset variable in a dictionary...bla, bla, bla. Maybe there are some missing mercurial or python modules. A quick check of the recommend and suggested modules with <c>apt-get</c> reveals nothing significant. Maybe the Python version is wrong. Well, look at that, Debian Etch is still using Python 2.4 by default. Python 2.5 was released in September of 2006. It's just possible that Mercurial---especially the perhaps less-well-tested CGI script---might be a wee bit surprised to find itself on a runtime that's almost three years out-of-date. That's a decent theory, I think. A quick <c>apt-get install python2.5</c> grabs the latest version from Etch (which is probably also horribly old, but no matter) and ... has no effect. The Debian installer does not set up the newer Python as the system default; it doesn't even ask if you'd like to do this. Perhaps there's a good reason for this...<fn> Long story short, I couldn't get the Mercurial 1.0.1 web CGI any more stable than it was on my initial attempt and must instead assume that it's just broken in that version. I rolled back to Python 2.4 and Mercurial 0.9.1 and everything started working again, though my eyes still teared up when I had to look at the repository web site. I couldn't figure out any way of getting a newer version of Mercurial to run on Debian Etch. A pity, but there it is. I ended up making my own theme and adjusting the style sheet enough so that I could use it less than an hour after having eaten without endangering my keyboard. I thought my Python/Debian adventures had ended until I started my server backup script, which uses <c>rdiff-backup</c> to synchronize several directories from my server. I use <c>rdiff-backup 1.1.15</c> on my Mac and remotely control an instance on the Debian Etch server. Setting this up with compatible versions was not the easiest thing in the world and seems to have been more fragile than I thought. My Python reconfigurations had removed <c>rdiff-backup</c> from the server because it had the <c>Python2.4</c> package as a dependency. I quickly re-installed <c>rdiff-backup</c>, but it was permanently offended and continued to give the same error message, which was, once again, something about some file or function or variable that it had expected to be set that was most emphatically <i>not</i> set and that it was going to, as a result, quit in a huff. I know that it's my fault for having used Debian Backports instead of being happy with three-year--old software, but knowing that doesn't make me any happier to be, once again, debugging a version mismatch error in <c>rdiff-backup</c>. I have, in fact, decided to tempt fate and forget about that part of the backup for this week<fn>. I'm sure my self from one week from now will bloody hate me for it, but I'm going to bed. <hr> <ft>This is perhaps the biggest difference between Perforce and Mercurial.</ft> <ft>An unfair jab, of course, because the whole point of using Debian is neither to stay on top of things nor to have things that look pretty, but to have a server that works, no matter what.</ft> <ft>That's what's known as "foreshadowing", because my decision to make Python 2.5 the default---if only for a little while---would prove to do horrible things to other software dependent on Python.</ft> <ft>Luckily, the Mercurial part is working as advertised. The backup for all of my projects now just executes a <c>pull</c> from all of those repositories, which happens in a flash. All in all, I'm quite happy with Mercurial, even though with 0.9.1, I'm still in 2005.</ft>