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 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.
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.