Kurt McKee

lessons learned in production


Hey there! This article was written in 2011.

It might not have aged well for any number of reasons, so keep that in mind when reading (or clicking outgoing links!).

The problem with Mercurial

Posted 17 January 2011 in feedparser and mercurial

There's been some talk on the feedparser mailing list about moving off of Subversion, and I think that's great! I used Subversion back when I was contributing to another open source project in 2006 and it was excruciating. Subversion's utter inability to merge made contributing a grueling chore, and I'll never forgive it for that. Plus, it's a centralized version control system, which is abhorrent to me. Subversion is the single worst version control system I've ever used.

My problem is that people who don't write code are set on migrating from Subversion to Mercurial. From my meritocratic perspective it seems like the Mercurial backers don't get a vote, but I'm working to ignore political issues. Besides, Mercurial (hg for short) has to be better than Subversion, right? Even though hg is also the only option to migrate to (Google Code only offers hg and svn), it's a distributed version control system like git so I could probably keep my same workflow. Unfortunately, after reading how hg handles branches I'm skeptical that it supports my workflow.

In git, branches are meta-data, so it all happens in one directory. In hg, the conceptual equivalent is to copy all of your files into a new directory and work on them in that new directory.

That's bullshit.

I peaked at 30 or 40 branches in my git repository, each representing a separate issue I had fixed but was waiting for review. I had exactly one directory in which all of that was happening. The equivalent hg workflow would require 30 or 40 cloned directories. Had I been using hg instead of git, there are several problems that hg would have presented while I was trying to get work done. I would have had to:

  1. ...copy BeautifulSoup to each repository. Feedparser relies on BeautifulSoup, but I don't, so I keep an unversioned copy in the same directory as feedparser.py so the full test suite will run no matter what branch I'm working on. I could install it in my PYTHONPATH, but I'd have to do so for each version of Python I have installed (I have six installed).
  2. ...deal with my testing script on a case-by-case basis. I run all of the unit tests in Python 2.4 through Python 3.1, and that's automated by an unversioned script with hardcoded paths, all specific to my configuration. I would have had to copy that script to each directory or install it globally and pollute my command tab-completion namespace.
  3. ...lose my get-to-work workflow. For my frequent directories I set a directory alias, so to get to work on feedparser I open a terminal and type cd fp, which expands to my feedparser dev directory. I'm not a fan of extraneous typing at the command line (hey, blog entries require revisions so I have to save keystrokes where I can).

These aren't insurmountable obstacles, but hg doesn't work the way I think, which makes it the wrong tool for me. As the only person who's writing code for what has been a dead project, I can only hope that git has good two-way Mercurial tools, or I fear my contributions will drop off. Seriously, I was given Subversion commit access this week and it's nearly completely killed my drive.

Yeah, Subversion really is that bad.