Why I Picked Mercurial

I was a little dubious about the hype over distributed version control until I bought Jon Loeliger’s excellent “Version Control with Git” at EuroPython last year. I was sold – it made sense. I’d used both Git and Mercurial a little before reading the book, but more out of necessity than design to be able to checkout fresh code from a couple of different open source projects. Like many people, I didn’t “get” DVCS at first – how could it possibly work in practice??? (The answer is: very well, thank you)

Deciding your choice of distributed version control is as much down to personal preference as your choice of editor, programming language, or operating system. Git impressed me by its massive range of tools, good Subversion interaction, pragmatic approach and the fact it’s great to drop the word “Git” into polite conversation. I have a lot of respect for Linus Torvalds and his pragmatic approach to development, and his decision-making process in crafting Git to make kernel development easier. The problem was that with great power comes great responsibility and, more importantly, complexity.

For personal development, I drifted towards Mercurial because it seemed to fit my development process much more comfortably, and had a slightly more elegant feel. The learning transition from Subversion to Mercurial was small compared to the transition from Subversion to Git. However, Subversion repository interaction from Mercurial is not so mature. Go figure. Despite that, Mercurial makes a great replacement for Subversion, eliminating all the niggles and problems of the latter. It feels more lightweight than Git, yet packs all the power and flexibility I need for the kinds of projects I work on.

Mercurial is written in Python, which is useful but not an essential reason, and very extensible. It works well on multiple platforms, while Git seems to be fine on my home OS environments (OS X, Fedora) but less developed for Windows which I have to use at work. Mercurial Queues are a fantastic idea that I really wish I’d had access to on several occasions in the past – they would’ve saved me so much time and pain. History can’t be altered, like in Git, although I do think the feature has its uses – just that it can also have its abuses. Mercurial seems to handle renames in a more natural way to me. HTTP-based sharing in Mercurial is pretty good, and efficient too.

Don’t get me wrong. I think Git is a fantastic piece of version control technology, and GitHub rocks as a supportive environment, but Mercurial has the edge for me. It rocks, and development is improving it at a respectable pace.

If you haven’t already seen Joel Spolsky’s Mercurial tutorial that has been doing the rounds, you can find it at: http://hginit.com/ – it’s the best introduction I’ve seen so far.

If you haven’t switched to distributed version control, take a look at Mercurial or Git (or Bazaar, if that way inclined) because it really is a significant evolution over centralised systems like CVS and SVN.


2 thoughts on “Why I Picked Mercurial

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 )

Google+ photo

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


Connecting to %s