After having asked the community about which decentralized versioning system W3C should use, we made our DVCS platform operational a few months ago, powered by Mercurial. The obvious contender was Git — here are some of the reasons why we picked Mercurial over Git, in the hope that this analysis can be useful to others.
Choosing a DVCS platform in an organization such as W3C is a lot more complicated than just following the trend, which seems to be in favor of Git today. For example, we had to take into account the tools coming along with the system and the clients available on the various operating systems used by the diverse set of Working Group participants and open source developers, as well as the support offered in third party softwares. Mercurial has clearly a superiority there over Git especially for supported clients under Windows.
A lot of our users are able to use the most advanced features of both DVCS but a significative part of them just want to share files, handle easily what they are doing, deal with conflicts and eventually being driven through a graphical user interface.
We haven’t heard any request for fancy history modification features: while Git is clearly more powerful in letting you manipulating your history, we liked the simplicity of the Mercurial command set and the availability of several GUI.
We will have to administrate a growing number of repositories. We knew before launching the service that we would have a lot of requests to tweak their configurations. As a result, the Systems Team needed something easy to set up, easy to hack on and also easy to integrate with our existing systems. Indeed, we couldn’t rely on any external hosting services like GitHub or BitBucket as we wanted all our repositories to be tied to our existing W3C accounts (through LDAP).
Looking into the future, we also verified the integration of Mercurial in Trac that we are considering using for some of our open source projects such as our Validators and Unicorn.
Mercurial has offered all those tools for a long time and lots of tutorials are easy to find on the Web.
To summarize, we liked both systems a lot. On the one hand, Git seemed to be more powerful, with more features but offered too much for what we needed. On the other hand, Mercurial came with more tools and seemed really simpler both for our users, and for us in terms of integration with other tools and services.
5 thoughts on “Why we chose Mercurial as our Decentralized Versioning System”
If your looking at Trac you should take a peek at its more able sister Redmine (redmine.org)
Nice, I hope you will be happy with Mercurial! Caveat: I’m a Mercurial developer, but I would still like to comment.
Many people have gotten the impression that Git is more powerful and can do things that Mercurial cannot, but this is false. The history models are the same and you modify history in the same way in both systems (by creating new history and destroying the old).
They differ in the way they expose the tools: Mercurial has a bias towards simplicity and towards not destroying history. But there is a number of extensions for Mercurial that enable history rewriting: rebase, mq, histedit, etc. The histedit extension is even modeled after Git’s rebase -i command. These extensions expose some of Mercurial’s API which has been there the whole time (the strip command, in particular), and built further upon it.
So please don’t add to the meme that Git is more powerful than Mercurial.
There are other critics too, e.g. that Mercurial can’t do octopus merges, but as a user I think they’d be nice not I don’t really miss them.
hg also works very well with Redmine, which we have been using at Zepheira. We have used Trac in the past, but project leaders needed more intuitive, flexible, and convenient controls over permissions and project components. Trac had a bit more of a learning curve in this regards, though it is OK.
We recently upgraded to Redmine 1.0.0.stable and plugged in all of our existing hg hooks, and it works great. One of our engineers was also able to get WebDav support working for managing project files. It is a good tool, and we are discovering new possibilities as we make local tweaks to its functions.
Addendum to my previous note: Redmine supports LDAP authentication in Redmine 1.0.0.stable.
Comments are closed.