Since my last post on the matter, I have had the opportunity to experiment with Mercurial and Git much more for my own projects in order to investigate options for the Wesnoth-UMC-Dev Project. A random forumer recently raised a stealth complaint against our usage of SVN, and he seems to prefer Mercurial (I can’t blame him for it, since SVN sucks at every conceivable level), but I don’t think it is the solution for our usage scenario.
To get it out of the way, I do use Mercurial to manage the Spanish translation for the Atheme IRC Services suite, and more recently, Hakone and Poison Ivy are hosted at Bitbucket (which is pretty cool, especially since it has out of the box support for CIA bot notifications).
The problem, as all Wesnoth-UMC-Dev related issues are, centers around the learning curve for non-tech-savvy newbies.
Mercurial uses a very strange user-level commit representation that involves a revision number and a hash, like 136:5c70e078efce (Hakone tip as of this writing). The only component in this commit specification that matters to most commands is the hash — the commit number is just there for decoration.
This is particularly jarring when history becomes non-linear.
changeset: 136:5c70e078efce
tag: tip
user: Ignacio R. Morelle <shadowm@xxxxxxx.xxx>
date: Sun Jan 09 03:37:37 2011 -0300
summary: application: Normalize capitalization of "Wesnoth-UMC-Dev"
changeset: 150:5c70e078efce
parent: 148:537ad43f161b
user: Ignacio R. Morelle <shadowm@xxxxxxx.xxx>
date: Sun Jan 09 03:37:37 2011 -0300
summary: application: Normalize capitalization of "Wesnoth-UMC-Dev"
These two commits are, as far as the content (diff) is concerned, identical. The only difference is that one resides within my local repository on my hard disk on a clean tree that doesn’t have any merges; the other is on the live Wesnoth-UMC-Dev website and has several merges resulting from the lack of the rebase extension in the Hg version we are using.
What’s wrong, you may ask? Those who are used to DVCSes won’t see anything of interest here. Those who are used to CVS or SVN will notice that the “revision numbers” in here differ for the same commit. Why is this? Because of the multiple merges down the history in the website’s repository. This is an arguably ridiculous case of non-linearity that could have been solved with the aforementioned plug-in if it were available on the system version we are running. However, it’s not too far from what would happen in an actual project with multiple contributors with direct commit access.
So, just like in Git, the ultimate solution for commit management is using hash specs. And that scares newbies because hexadecimal numbers are 1337 |-|/\XX0|3 stuff or something.
But unlike Git, the solution to our problem requires manual activation (~/.hgrc), and isn’t built into older Mercurial versions.
[extensions]
hgext.rebase =
Does this make sense to you? Good, because it doesn’t to me. Maybe it’s a cool way to demonstrate how extensible your VCS can be, but for me this is just ludicrous.
Git, on the other hand, is as bloated as a Swiss Army Knife, and you might not even need most of what it ships with — which is good, because not all of us are Linux kernel developers. Fortunately, the authors are not evil enough to try to lure unsuspecting clueless users with fake revision numbers.
(Incidentally, Mercurial is implemented in Python. And I hate Python, as you know. Coincidence? I think not.)