Consider Mercurial (Yes, Mercurial, not Git)


Mercurial will be the 3rd version control system I’ve used since I started programming professionally. The first was SourceSafe. The second was Subversion. And now we’ve migrated all our source code to Mercurial.

Often I’ll be asked: why did you not pick Git?

That’s a fair question. Everyone seems to loves Git these days. But I think more precisely, everyone loves GitHub. I love GitHub too, I use it for all my personal projects, but in terms of how I manage code for my employeer, things are a little different. I can’t justify moving 15 year’s worth of intellectual property to GitHub just yet. Having our entire code base in the cloud is a hard a sell to management, and I have plenty of low-hanging fish to fry (mixed methaphors intended) without putting energy into that. Of course, we could have taken a look at GitHub Enterprise, but there was no budget for this move.
But there is another reason why we can’t use Git effectively: Windows. We are using Windows 7 for day-to-day work and that is something that is unlikely to change in the medium term. (I actually don’t mind Windows 7. I own a Mac and I use it for my personal projects; I’ve dabbled with Unbuntu. But getting my team kitted out with *nix systems is another challenge I’ll put aside for now.)
The current status quo as regards using Git with Windows is – unsuprisingly – Git for Windows which provides a *nix style shell for working with Git from the command line. This isn’t bad, but I dislike the idea of adopting a new technology on a platform that isn’t even in the thoughts of the tool maintainers.

But we still wanted distributed version control. We were stuck with Windows and we didn’t have the lure of GitHub to look forward to. We still wanted that ‘branch-y’ type of development. For these reasons, we found ourselves looking ever closer at Mercurial.

Mercurial Works

Mercurial just works on Windows. The definitive Mercurial book (written by Bryan O’Sullivan – a fellow Irishman) is concise, and exhaustive. Better yet, if you want that warm fuzzy feeling a GUI gives you, then look no further than TortoiseHg – a top quality tool. That said, we trained the team up using Mercurial on the command line. I wanted everyone to understand how Mercurial worked, and how it was different from SVN. I am really happy we took this approach – I really wanted the team to understand their new tool.


Our Mercurial move had a steep learning curve, especially for those developers that had no exposure to Git or any other DVCS. We had to plan our move carefully to avoid a change-over meltdown, even for our small team of seven. There are broad similarities between Git and Hg, but the syntax can be confusingly different, especially when the SVN mental model is still stuck in place.
The first day saw a lot of abandoned branches, incorrect merges, and a general realisation that understanding the tools you use everyday is going to be paramount in this brave new world.
It also quickly became apparent that the ‘branch-y’ model we were adopting could get very complicated when you are working once something more complex than a micro-blog. Branches needed to be shared, and they need to be merged. Working copies on developer and test machines had to represent particular branches and this all has to be managed. It think it is fair to say that some amount of complexity has been created, and this is the cost of the amazing flexibilty we now have.

Our Workflow

Here are some bullets points describing our Mercurial workflow:

  • We work from a central repo called ‘master’. All dev repos are cloned from this.
  • Developers create named feature branches (not bookmarks) for everything except the simplest changes. These branch from the default branch.
  • Developers prefix named branches with their initials, and then close all branches once they’re finished with them to avoid cluttering up the global branch list.
  • Where shared work is required, a developer can push branches they wish to share to ‘master’, and other devs can then pull those branches.
  • We have many local websites. We generally have a Site X cloned from ‘master’ for general dev. We then have Sites A to C – each of which is cloned from Site X – for branch testing. Using this approach, a developer can create a feature branch on Site X, make their changes and commit it. Then they can pull the changes from Site X _into_ Site A and update the working copy to that branch. They then tell the user to test away on Site A while they can get back to Site X and branch their next feature. And on and on.
  • Once testing is complete, the developer can create a code review from the diff between the feature branch and the default branch (having of course merged default into the feature branch first). Once complete, we can simply merge our feature branch into default and push to ‘master’ so everyone else gets our tested and reviewed changes.

hg ci -m “Wrapping up.”

So that is how we use Mercurial in a nutshell. It is complex; way more complex than SVN. You need to know how Mercurial actually works to get the best out of it, whereas perviously with SVN you could get away with not really engaging fully with SVN due to how simple it was.

But Mercurial is very flexible. And while not bullet-proof, with a decent dollop of inter-developer communication we’re making it work well for us. So if you need a DVCS, and especially if you are on Windows – consider Mercurial.

About these ads
This entry was posted in Uncategorized and tagged , , , , , . Bookmark the permalink.

9 Responses to Consider Mercurial (Yes, Mercurial, not Git)

  1. xenji says:

    Pretty nice post, but I do not see the reason for not using git on Windows. Mysysgit works like a charm (It did not always work like that, I know) and gitosis or gitorious are good alternatives to private github repos or github enterprise. Gerrit enables you to create commit based code reviews. I really do not understand that using Windows is the key problem in your decision process.

    Please don’t get me wrong, I like both systems and I am pro any switch from any centralized system.

  2. Interesting, do you think you could document more of a complex workflow? Similar to

  3. Rocco says:

    I’m a great fan of TortoiseHg, but am perplexed how this would be considered a reason to use Mercurial over Git (hint: Also, consider git-flow (posted above by Mark Ellul) as a more transparent development model. Multiuser git server is very easy to configure and maintain, but I’d mention Gitolite and Gitlab as a newer (and arguably better) options to Gitosis and Gitweb.

    Maybe I’m being unfair, but in my mind you fail to provide realistic reasons for your decision.

    • ciaranarcher says:

      @Rocco – TortoiseHg was not a reason to use Hg over Git, it was the icing on the cake. Like I said, we trained the team to use Hg from the command line from the get-go and I personally really only use TortoiseHg for browsing branches diagrams, etc.
      Also some of the option you mention above are not Windows-friendly, for example the min. requirements for Gitolite require a *nix system.

    • OCTAGRAM says:

      I’ve tried TortoiseGit, it is not nearly as pleasant as TortoiseHg. However, I found a plugin named hg-git.

      I’ve cloned

      Then I’ve copied hg-git/hggit subdir into TortoiseHg/contrib/

      Then I’ve edited my Mercurial.ini and added:

      hggit=C:\Program Files\TortoiseHg\contrib\hggit

  4. aem says:

    Re: the comment “I do not see the reason for not using git on Windows”. Well how about because it is broken? See This has been broken for over two years and no fix is in sight. We moved from git to mercurial because of this.

Leave a Reply

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

You are commenting using your 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