Atlassian sunsetting mercurial support in BitBucket

michelemauro profile image michelemauro ・3 min read

(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?


Editor guide
syntaxseed profile image
SyntaxSeed (Sherri W)

This turn of events is pretty distressing for me. I chose Mercurial about 10 years ago as a new freelancer- not wanting to use Visual SourceSafe like my employer.

First I used it only locally - the TortoiseHg GUI made it so, so easy. I then self-hosted the repos literally on shared hosting - that's how simple it was. I later moved to BitBucket for the added features & "stability" that a cloud service would provide.

Fast forward 10 years & I have DOZENS of client & personal repos on BitBucket. I'm still a freelancer & only working part time till my youngest child starts school next year.

So, migrating will be a HUGE project that I don't have the time for. I don't blame BitBucket for dropping Mercurial.... Git has clearly 'won' despite being WAY more complex & not having great GUI options on Linux. But the short timeline & lack of automatic migration from BitBucket is a crappy move. I'll be looking at GitLab or GitHub as my replacement.

Sigh. Wasn't prepared for this ON TOP of the huge PHP 5.6 -> 7.3 migration I'm also slogging through.

michelemauro profile image
michelemauro Author

After working around it a bit, I'm testing SourceHut: it looks as an interesting idea, very minimal, very alpha, very simple and focused.

They welcome Bitbucket refugees 😁

syntaxseed profile image
SyntaxSeed (Sherri W)


So far I'm having luck migrating them to Git and moving to GitLab.

amphyby profile image

take a look at the codebase too. Moved there and pretty happy :)