Decline of Mercurial

04 September 2019
Today I found out that Bitbucket is discontinuing support for Mercurial, purely by accident when I created a private repository for some draft website texts. This was a bit of a surprise since Bitbucket's heritage is starting out as a Mercurial equivalent of GitHub, but I am not particularly shocked by the move. I still use Mercurial for non-professional purposes, but I had been wondering how long this would last.

Differing philosophies

The fundamental difference between Mercurial and Git is their target audiences. Mercurial was designed to faithfully preserve how development progressed, with the immutability of history at least initially being a major selling-point, which would have been a major political point for those moving over from Subversion. In contrast Git was designed as a patch management system for the Linux kernel, reflected in the core assumption that “a change will be merged more often than it is written”. It is intended for reviewers who are only concerned with patches and not the history of how an individual patch was developed, and many of them will simple be thrown away.

My preferences

When I was first choosing between between Mercurial and Git I felt that Git was over-complex and like many others was adverse to the whole idea of rewriting history because it sounded like potential data-loss — I first got into CVS as a way of backing things up so the latter fear should not be underestimated. Mercurial also had some fringe benefits such as a built-in webserver that Git did not have, but the ultimate clincher was that Git had no real support on Microsoft Windows — Windows users were basically fobbed off with cygwin which from my experience at the time was unreliable. This mattered because it was only sometime in 2014 I finally stopped using Windows completely for software development.

My first major exposure to Git was using it as part of Gerrit, which properly introduced me to not only just branching, but the idea of keeping a tidy central branch. I tried emulating the approach with Mercurial, but at the time it was a work-flow that Mercurial had yet to embrace. Using Git professionally on a day-to-day basis made me familiar with all of Git's little tricks, whereas what little use I made of Mercurial for personal projects was pretty basic. When it comes to wanting to use those tricks for personal projects, it is easier to simply switch over to Git completely than work out how Mercurial can do them these.

The turning point

In my view what killed Mercurial was continuous development. Continuous integration institutionalised the idea that software development should be modelled after self-contained patches to a master branch, which in turn are developed on small throw-away branches. For good or bad this work-flow is more or less universal in IT outfits, especially ones that graduates would have had to start out in, and anywhere that is not using either Git or a Git-derived system like Gerrit is probably not using version control at all. Stackoverflow stats for 2018 show Subversion

The prognosis

The big practical difference is that by default Mercurial commits all changes to tracked files, whereas with Git the default is the complete opposite of not committing anything — in practice I now prefer the latter in most cases. These days the only thing I have really used Mercurial for is printed circuit board projects, and these consist of a lot of repositories that individually only include a few files. For my websites I think Subversion is a better choice given it has the changelist command — ironically I did implement a Mercurial extension that did the same thing but not sure where the code has got to.

I current use three different source control systems and the closing down of Bitbucket's Mercurial hosting does make me consider the prospect of retiring Mercurial. The forcing factor is that I am making increased use of Bitbucket for cross-system transfer of personal projects, so I can no longer use Mercurial for anything that is likely to go anywhere other than stay on my desktop.