Atlassian sunsetting mercurial support in BitBucket

(I didn't expect to start writing here with a text like this. But since I'm looking for longer opinions that those that can be found on twitter, I thought it would be a good place to start, and a good topic to talk about.)

The headline came to me via whatsapp from an ex-colleague: Atlassian sunsetting mercurial support in BitBucket. That was really a hard hit.

For those who don't know, Mercurial was one of the first really distributed Distributed Version Control System that really took traction: it was started in 2005, and it is still heavily used: Mozilla, Vim and OpenJDK are some high-profile projects that host multiple years of development, and millions of lines of code in hg repositories.

I started using Mercurial before git ever became mainstream, and because I was working with some colleagues outside the main office: we needed to collaborate on the same sources and, in that setting, we couldn't reach our central CVS. The ease of use of passing around "boundles" of commits, the simple commands and the almost impossibility of losing history made it possible to work for many months without even a central server, just passing files via skype.

It was no match for what Git was at that time (early 2007): something Linus whipped up in a couple of weeks, not too stable, still optimized for the Linux use case and adventurous to use outside of it. Mercurial was already stable, well supported on windows, too, with a clear and well-thought model that was easy to understand and use.

Twelve years later, git is still making releases with new commands to clarify and simplify some use cases, while Mercurial releases are about technology updates and new features. You can easily find (and probably need) tons of tutorials on how to use git and how to understand its peculiar concepts (like of course the excellent one here on DEV); meanwhile, every colleague I exposed to mercurial never needed any special training nor never lost work because of a detached head or a push in the wrong branch, no matter its previous level of expertise.

Finally, in the last three-four years, the "GitOps" methods fueled the exponential growth of Git integrations, and we're now stuck in VHS land. Atlassian, of course, has a bottom line to keep in check and finally came to the conclusion that BitBucket is supporting one VCS too many, and the one used by "1% of the users" has to go. The irony of BitBucket being the first commercial solution for Mercurial is, of course, only adding sadness to this story.

The options that Atlassian proposes are really underwhelming: a yet-to-be automated conversion service, some self-hosted pointers (Heptapod and Kallithea seem to be the most interesting; but they are a far cry from a supported commercial service with more than 10 years of experience), or do-it-yourself. And don't expect to keep PRs, comments, issues, metadata: no export path for them, nor conversion of project structure. When Atlassian pulls the plug in mid-2020, they'll be gone.

That's a sad, sad turn of the story that will harm a really good project, a true Betamax of the VCS space.

I wish however to thank a lot the original BitBucket team, that in 2008 believed in Mercurial and started its journey. Atlassian, while can be understood as a business entity, is still struggling in executing major moves like these while minimizing bad publicity and juggling worse karma; meme writers will just have more things to poke fun at.

Of course, the main lesson here is, for the n-th time, be careful what you put on a cloud service. And you, what do you have on a cloud service? what part of the information about your projects (issues, discussions, decisions, permissions, people) will you be able to offload, reuse and recycle if your current provider pulls the plug on its service or part of it?