Having moved from ClearCase to Mercurial last year, I have gone through the alteration to workflow that many users must get over on when switching from Subversion or CVS to Git or Mercurial. If you want to read a younger, fresh faced novice's take on the advantages of this, you can read this blog from 6 months ago Why Embrace Distributed Version Control Systems.
Today I'm going to focus on the Enterprise user, and why Mercurial matches many of the needs that an Enterprise has, such as easily on-boarding non-technical people, and keeping the history of development clean for all those ISO standards and Government security clearance audits.
Adios ClearCase
I must admit that ClearCase had burned its bridges with me before I made the jump, as I was positively frustrated with it. It was so slow that I would check in commits before lunch and hope they were done when I got back. I also had a rule that I would not checkin or checkout large chunks of work after 3PM. It was either that or start drinking at my desk!
Trying Git
Prior to the change I had been playing around on Github to learn the basics. I wanted to make the switch from ClearCase to Git seamless, particularly due to that famed complexity, and then Mercurial happened.
I found that playing around on Github to be very helpful in understanding the basics, but working on your own side projects is a lot different to working professionally and having many people push and pull to your repository. Especially the merging conflicts part which I never really dealt with in ClearCase. You can read last weeks blog where I refer to the merge fun as a
goat rodeo.
Now that I use Mercurial for work, I'm going to run through my own list of pros and cons, and how they can be applied to an Enterprise's needs.
Learning Mercurial is Easy
Mercurial is pretty straight forward and the learning curve is not too steep. After a few days, the basics become natural and once the proverbial hits the fan you will quickly learn how to merge conflicts, cherry-pick changes, or rebase. It's made that bit easier because the commands just make sense, in my head anyway, and the documentation is pretty good at explaining functions.
My take is that the ease of learning would benefit an Enterprise by allowing a smoother transition for developers from Subversion to Mercurial. The ease of use also has extra benefits for the non-technical players in a development team: designers, writers, and usually managers!
Enterprise Needs Easy
In an Enterprise environment that often has more testers and technical writers than developers, the technical debt of these users needs to be taken into account. That's before I even start on the summer interns and co-op students!
In my experience, as a semi-technical user of VCS, the transition to Mercurial was a bit smoother and easier than to Git. This is of course based on the extra confusion I felt when moving to Git as it was my first DVCS, and also because a lot of blogs make the same claim too, so I'm happy that this selective choice of evidence backs up my theory.
Mercurial History is Safer
Call me cynical, but the main thing that differentiates an Enterprise from an ordinary business is the almost legalistic way in which blame is attributed, evidence of wrong doing collated, and when something goes wrong everybody gets busy proving they were right.
Another, more Marketing speak, way of phrasing this is compliance and audit trails.
Git Might Be Too Flexible
With the basic implementation of Git, there is very little you cannot simply use with \--force and get away with.
With Mercurial it is a little harder as the basic implementation does not contain the extensions for changing history. You can change the history locally, but once you try to push remotely, you can't. Mercurial will abort the push, and make a new head like in this example.
searching for changes abort: push creates new remote head 57951a65fca9! (merge or see "hg help push" for details about pushing new heads)
Once those two heads are merged, you can see how the history of both is kept.
With Git, changing this history would be a trivial task and I could hide the fact that I caused a new head when I didn't commit correctly. Of course 99.99% of the time this is irrelevant, but that .01% of the time when you want to blame someone (ahem, I mean be compliant) it would be good if it was a little harder to change the history.
You can of course implement a workflow that prohibits these shenanigans if you so wish, but that is available in both Git and Mercurial. We are focussing here on the out-of-the-box implementation.
Even then, most of the extensions used to make changes permanently back up any changesets that they destroy into a bundle. These bundles will not be garbage collected by Mercurial. With Git you can find changesets that you've altered using git rebase with the interactive git reflog command, but if it has been more than a month since you made the change, those changesets will be
lost as Git will garbage collect these after one month.
This is another aspect of Mercurial that keeps the history of a repository pretty solid.
Changing History in RhodeCode Enterprise
With RhodeCode Enterprise, changing the history on the server is an even more complicated affair, and this is what keeps it relatively secure for Enterprise users. To change the history you need to install RhodeCode Tools, make an API call to strip the history all the way back to a commit that is the same in both the remote and local repository, and only then can you push the commits with altered history, without the server complaining.
Conclusion
Mercurial is very similar to Git, but with a few different angles that make it a little more Enterprise Friendly. The different ways in which history, command-line utility, and Windows support are handled means that it covers a wider range of Enterprise concerns when doing a tools analysis of a potential technology.
When there are more things to be considered than just keeping developers octomerging from the command line, and with Facebook and other large players using Mercurial, then there is no question that it scales!