Promit's Ventspace

October 6, 2010

Evaluation: Mercurial

Filed under: Software Engineering — Promit @ 11:13 am
Tags: , , , , ,

I’ve been a long time Subversion user, and I’m very comfortable with its quirks and limitations. It’s an example of a centralized version control system (CVCS), which is very easy to understand. However, there’s been a lot of talk lately about distributed version control systems (DVCS), of which there are two well known examples: git and Mercurial. I’ve spent a moderate amount of time evaluating both, and I decided to post my thoughts. This entry is about Mercurial.

Short review: A half baked, annoying system.

I started with Mercurial, because I’d heard anecdotally that it’s more Windows friendly and generally nicer to work with than git. I was additionally spurred by reading the first chapter of HgInit, an e-book by Joel Spolsky of ‘Joel on Software’ fame. Say what you will about Joel — it’s a concise and coherent explanation of why distributed version control is, in a general sense, preferable to centralized. Armed with that knowledge, I began looking at what’s involved in transitioning from Subversion to Mercurial.

Installation was smooth. Mercurial’s site has a Windows installer ready to go that sets everything up beautifully. Configuration, however, was unpleasant. The Mercurial guide starts with this as your very first step:

As first step, you should teach Mercurial your name. For that you open the file ~/.hgrc with a text-editor and add the ui section (user interaction) with your username:

Yes, because what I’ve always wanted from my VCS is for it to be a hassle every time I move to a new machine. Setting up extensions is similarly a pain in the neck. More on that in a moment. Basically Mercurial’s configurations are a headache.

Then there’s the actual VCS. You see, I have one gigantic problem with Mercurial, and it’s summed up by Joel:

Whereas, in Mercurial, all commands always apply to the entire tree. If your code is in c:\code, when you issue the hg commit command, you can be in c:\code or in any subdirectory and it has the same effect.

This is an incredibly awkward design decision. The basic idea, I guess, is that somebody got really frustrated about forgetting to check in changes and decided this was the solution. My take is that this is a stupid restriction that makes development unpleasant.

When I’m working on something, I usually have several related projects in a repository. (Mercurial fans freely admit this is a bad way to work with it.) Within each project, I usually wind up making a few sets of parallel changes. These changes are independent and shouldn’t be part of the same check-in. The idea with Mercurial is, I think, that you simply produce new branches every time you do something like this, and then merge back together. Should be no problem, since branching is such a trivial operation in Mercurial.

So now I have to stop and think about whether I should be branching every time I make a tweak somewhere?

Oh but wait, how about the extension mechanism? I should be able to patch in whatever behavior I need, and surely this is something that bothers other people! As it turns out that definitely the case. Apart from the branching suggestions, there’s not one but half a dozen extensions to handle this problem, all of which have their own quirks and pretty much all of which involve jumping back into the VCS frequently. This is apparently a problem the Mercurial developers are still puzzling over.

Actually there is one tool that’s solved this the way you would expect: TortoiseHg. Which is great, save two problems. Number one, I want my VCS features to be available from the command line and front-end both. Two, I really dislike Tortoise. Alternative Mercurial frontends are both trash, and an unbelievable pain to set up. If you’re working with Mercurial, TortoiseHg and command line are really your only sane options.

It comes down to one thing: workflow. With Mercurial, I have to be constantly conscious about whether I’m in the right branch, doing the right thing. Should I be shelving these changes? Do they go together or not? How many branches should I maintain privately? Ugh.

Apart from all that, I ran into one serious show stopper. Part of this test includes migrating my existing Subversion repository, and Mercurial includes a convenient extension for it. Wait, did I say convenient? I meant borderline functional:

Subversion’s Python bindings are a prerequisite. The bindings (generated with SWIG) are installed separately on Windows, and can be found on http://subversion.tigris.org/ . Note that you can’t do this with the Win32 Mercurial binaries — there’s no way to install the Subversion bindings into its built-in Python library. So you’ll need to use a Mercurial installed on top of a stand-alone Python, and you may also need to do something like “set HG=python c:\Python25\Scripts\hg” to override the default Win32 binaries if you have those installed also. For Mac OS X, the easiest way is to install the CollabNet Subversion build, and then copy the content of /opt/subversion/lib/svn-python to the site-package directory of the python installation.

The silver lining is there are apparently third party tools to handle this that are far better, but at this point Mercurial has tallied up a lot of irritations and I’m ready to move on.

Spoiler: I’m transitioning to git. I’ll go into all the gory details in my next post, but I found git to be vastly better to work with.

About these ads

7 Comments »


  1. > When I’m working on something, I usually have several related projects in a repository.

    Don’t do that. Use *separate repositories* for *separate projects*.

    This applies to any DVCS.

    Comment by Jakub Narebski — October 6, 2010 @ 1:55 pm | Reply

    • Yeah, for some reason I found that DVCS fans tend to say ridiculous things like that — almost as if it were some kind of obvious fact that any other way than theirs is a bad idea and therefore the VCS should interfere directly with your workflow. I think it’s quite bizarre.

      Comment by Promit — October 6, 2010 @ 2:01 pm | Reply

      • The opposite is true: keeping unrelated projects in one repository in CVCS stems from the fact that early CVCS (like e.g. CVS) were loose collection of per-file histories / version control.

        Or perhaps it is bad translation of using single central place (single SCMROOT) in CVCS into single repository in DVCS, instead of correspondence being module / project in CVCS and repository in DVCS.

        Comment by Jakub Narębski — October 7, 2010 @ 1:39 pm | Reply

  2. Sounds heinous. I’ve tried Bazaar and Mercurial so far. I don’t primarily work on Windows, so I don’t have many of the same problems that you have, but I have one you probably share even though you didn’t mention it: they are S-L-O-W. Maybe it’s because they’re written in Python and have to spin up the interpreter for each command invocation?

    Whatever, the sluggishness is enough to make me consider git, too. However, git also has “Windows aversion syndrome,” and while I don’t work on Windows much, my open source project is available for Windows, OS X and Linux which means that I need a setup my Windows users can deal with easily (and they’re not the most technical bunch, being a tool for artists – then again, most don’t build from source…)

    There’s still plenty of room for improvement in the DVCS arena.

    Comment by Oluseyi — October 6, 2010 @ 3:01 pm | Reply

    • I have not done any kind of speed testing with any of the tools. However, I’ve never thought of Subversion as being a fast system. Supposedly git is slow on Windows because of poor ‘fork’ performance but I haven’t noticed anything out of the ordinary yet. I fully expected git to be awful on Windows and surprisingly enough, that is not the case. More on that in my next entry.

      There’s still plenty of room for improvement in the DVCS arena.

      Oh that is so very true. SVN may be less preferable in terms of its core centralized model, but the system and tools are so vastly more mature.

      Comment by Promit — October 6, 2010 @ 3:16 pm | Reply

    • It’s interesting that you bring up both Bazaar and Mercurial being slow, because Bazaar is COMPLETELY slow in every single way, and I recently had a job where I was able to evacuate the projects to Mercurial from Bazaar.

      I’ve found that it’s a lot faster in most regards, but actually establishing a new repo from an established one is absolutely ridiculous. Transferring all those changesets, I suppose.

      Comment by AndrewBC — October 7, 2010 @ 11:43 am | Reply

      • Actually Bazaar performance (from what I heard) improved significantly in the new version, being now on par with Mercurial.

        Comment by Jakub Narębski — October 7, 2010 @ 1:35 pm | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Rubric Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 787 other followers

%d bloggers like this: