A Mercurial Hopeful
A stubborn persistence to the DVCS that can.
A couple of years has passed since the dominance of git in the developer’s world. It’s a weird ecosystem when you see Microsoft and Apple wholeheartedly use git as if they were the pioneers of the darn thing. However, while the big corps have been focusing on the dominant, one little version controller has kept chugging along; mercurial. It has refined its strengths and narrowed its weaknesses. In my opinion, if people gave mercurial a true look, then the version controller may see a very strong uptake.
I say this, but I didn’t start off as a mercurial preacher. For my transition to distributed version control (DVCS), I started with git. Once Linus Torvald released the work, none could persuade me to try something else. It may very well be that my sole dependence to git came from the horror of being a cvs user for a little too long. Or the fact that actually using offline distributed production is more feasible with git. Ironically though, the central host repository really has helped dumbify the centralization of the whole code management process on git, which makes the above point almost mute. In any case, git really took me for a good ride at better organization.
So while I was happily using git for everything, I began to dream of a better way of doing the version controlling. You see, while git is well equipped for a host of circumstances, it can be a complete labyrinth of daunting frustrations. So out of some weird coherency, I began hearing the gospel of Mercurial. The DVCS was not too far off syntactically from git. As such, it made mercurial quite easy to get started with. However, after a few practiced tries with it, I realized the powerful semantic differences. The main one (if you never used a centralized version controller before) would be branching.
As anyone that has put a hand in git knows, the idea of branching in git is really the selling feature of the DVCS. It makes the idea of writing up little experiments here and there a breeze. So when jumping to mercurial, my first thought to do the same thing with it brought me a whole set of agony. The reason is simple. Mercurial’s named branching is actually something else entirely. The named branches are actually strong branches in the likes of centralized version controllers of old. As such, these branches should be treated as immutable trees to the repository and not as weak branching like git.
This is where most fall out from using mercurial and end up never looking back. For me though, it was only a slight annoyance to a better understanding. I ended up realizing mercurial doesn’t have one structure to branching but three. Not only does mercurial use strong branching through the named branches, but it can also do weak branching like those of git using bookmarks. Then what about the third form of branching, considering strong and weak are the usual suspects?
Mercurial also has the ability to do multiple nameless head branching or commonly known as anonymous branching. It’s something like weak branching, where the mutability is a fluid as you want it to be. You even create them the same as a you would a weak branch, with one exception. Instead of naming the weak branch with a bookmark, you simply commit your work instead. Here’s where the branch gets the name anonymous from.
With the anonymous branch, mercurial ends up making an entirely new head to your repository. It’s as if a tiny fork was just produced and you can do with it your will. You can add bookmarks to the anonymous branch making it a weak branch. You could also add multiple bookmarks to it and the original head, ending up with one interesting cluster of side ideas in your work. The choices end up becoming really what you need. And the best part of this anonymous branch is that you can always return the repository back to a singular head. In fact until you make it highlander and exist with only one, you can’t actually push upstream your multiple head monstrosity by default. It’s your experimental stage of your work and something that really shines with all the other extra capabilities of mercurial.
Learning of anonymous branching really sold me mercurial. I ended up staying with the group and never leaving. The power of being able to use the tool to shift and turn how I work is what kept me. In git, I always felt and still feel like I’m fighting with the tool to do my bidding. It’s a constant battle to do what I need to do with git. And I don’t think I’m alone. Git has such a strong focused way of work that the usual strategy is learning the ‘gitflow’ way of working with git. Then you end up tuning your workflow towards something which works with it. It’s not like the workflow doesn’t actually work. For me, I rather let circumstances of my project detail what workflow I follow and then use the tool to achieve it. Hence, I’m still here with mercurial and I’ll probably stay with it until the better version controller implementation is created.
