Mercurial Support in TFS: Declined

January 17, 2014 • ∞

Yesterday it was announced that Microsoft will not be adding support for Mercurial to Team Foundation Server.

I see two reasons why this might have happened.

Mercurial Core and Licensing Issues

There is a way of comparing and contrasting Git and Mercurial I came up with recently. Git is simple on the inside (with its ingeniously simple and elegant storage format) but overly complex on the outside (with its cumbersome and often illogical CLI). Mercurial, on the other hand, is quite complex on the inside, but has a refreshingly simple CLI.

This observation has far-reaching consequences.

Git, with its simple and-well documented storage format, makes it easy to do a clean room implementation of Git Core in any programming language. Clean room implementation effectively frees authors of GPL restrictions and allows this code to be used in any closed-source product.

Even if not for a possibility of a clean room implementation, libgit2 (which is what Microsoft uses internally) is licensed under GPLv2 with Linking Exception, so incorporating this library into Visual Studio and Team Foundation Server is a no-brainer technology-wise and licensing-wise.

When it comes to Mercurial, matters are significantly more complex here. Low-level Mercurial internals are documented only to a degree, which makes it impossible to implement Mercurial Core using clean room approach. This means that any reimplementation will automatically be treated as derivative work, which forces it to be licensed under GPL, which in turn prohibits usage of the library in a closed-source commercial project.

It’s unclear to me if this issue can be resolved at all. If Microsoft eventually decides to add support for Mercurial to Team Foundation Server, there are several options for them here:

Use the Command Server approach, which is the only legal option for the time being, albeit overly cumbersome.

Reach an agreement with Matt Mackall, Facebook and numerous Mercurial contributors so that Microsoft will be granted a permission to use Mercurial under different license.

Suffer through a complete rewrite of Mercurial without even attempting to take a peek into original source code.

Git Popularity

Comparing absolute numbers of developers using either VCS, Git is indeed more popular than Mercurial, so with Team Foundation Server integrating with Git Microsoft caters for a larger target audience.

Or it does not?

In absolute numbers Git is more popular, but Mercurial is arguably more popular in a corporate world and even more so in companies that are building on Microsoft stack and are using Microsoft products, client and server alike. It’s unlikely that the OSS community is the target market for either Visual Studio or Team Foundation System.

Mercurial Plugin Ecosystem

This is a minor point that is unlikely to have influence Microsoft’s decision, but it’s worth mentioning nevertheless.

Mercurial plugin ecosystem is richer than that of Git and, thanks to a nicer API of Mercurial, its extensions seamlessly integrate into Mercurial proper. Most notably, hg-git is significantly simpler to install than its’ Git counterpart, git-remote-hg, with latter being less feature-rich.

Again, this alone is unlikely to have had any significant weight in a decision to decline the UserVoice request, but it might have left Microsoft thinking that this will somehow satisfy us Mercurial aficionados.

All in all, this is an unfortunate piece of news for several thousand developers and several hundred companies. Let’s see what the future holds.

Subscribe to the HgLab HQ Newsletter →

Please enable JavaScript to view the comments powered by Disqus.

Disqus