Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

What to do with your Mercurial repos when Bitbucket sunsets support


Not many people know this, but Perforce has a Mercurial hosting service in the cloud, called Helix TeamHub. It also supports Git and SVN in the same user interface.

Helix TeamHub is free for up to 5 users and 1GB of data storage. HTH, as we like to call it, has a simple, elegant user experience, complete self-service administration. I've seen questions about roadmaps and "seriousness" about supporting HG (not aimed at us, just in general).  I can't talk about the Perforce roadmap (perhaps we will cover that in a blog on in the future) but I can say we are serious about listening to our customers and trying to giving them what they want.

Like # people like this

Have just moved my stuff to Github. Works like a charm for code in both Hg and Git, but not so good for issues and wiki. Is there a nice one-click solution to move them around as well? 

Also GH immediately found a few vulnerable packages in my dependencies, not something I would expect from a source control, but a nice feature indeed.

@Ed Lomonaco @Alex Bream TortoiseHg website is I am not sure whether it is developed by Bitbucket team or another volunteer. It is a different product from Mercurial itself.

@vorapoapTortoiseHG website mentions: "Hosted by Bitbucket", just because repos hosted on BB, but it's in any way independent from BB|Atlassion project of THG's team

GIT can git.  Atlassian can git. Very lame excuse to wipe out an extremely good version control system.  It is very, very upsetting that you guys have encouraged an monopoly.  I really hope a valid contender comes in to wipe out Atlassian in the same fashion as yo are doing with this move,

Like CharlieC likes this

Two years ago, when Atlassian announced they weren't adding Mercurial support to Bitbucket Server, a few Atlassian employees showed up on Reddit to reassure users:

Bitbucket Server PM here. Atlassian does care about Mercurial, as explained in the posted page. Although it isn't a priority to add to Bitbucket Server, Mercurial is actively supported in Bitbucket Cloud, Bamboo, Fisheye, Crucible, SourceTree.

On Bitbucket Cloud we're very commited to continuing support for mercurial. We employ a core contributor on mercurial and he recently added support for evolve to Bitbucket Cloud. There are no plans to drop support any time soon and we still consider (and do our best to include) hg when developing new features.

Bitbucket Cloud ( has always had Mercurial support and we plan to continue supporting it. It has a loyal following, and established investment, as demonstrated (I hope) by the expressions of the awesome and passionate Mercurial developers on the Bitbucket team who have weighed in here already.


Like # people like this

@Jesse McGrew Classical proverb


Time Changes , People Changes.


@Jesse McGrew , wonder if those passionate Mercurial developers still work at Bitbucket.

@vorapoapthat just means it's hosted with bitbucket, though not for long...


atlassian makes sourcetree, which is an awful excuse for a VCS tool.

Like __jtalk likes this

Nice to know how much Atlassian doesn't care!

Like __jtalk likes this


The Bitbucket team arrived at our current Mercurial deprecation plan after lengthy research and thorough analysis.

We investigated several solutions. Regrettably, due to the infrastructure of the Bitbucket platform, solutions such as supporting Mercurial repos in read-only mode would require similar resources as continuing to support read/write repos.

We realize that this can be frustrating. We have decided to provide a long deprecation window with this in mind and are hopeful that our team can help you identify the right migration or conversion path during this time.

It wasn't an easy decision to remove Mercurial support. Mercurial holds a special place in Bitbucket history and we're especially thankful for the support we received from this community in the early days. We recognize that Mercurial use cases are diverse and there's no one-size-fits-all solution. That's why we've turned to this forum as an open exchange with the community to share and discover the best solution for your team.

Tom Kane Atlassian Team Aug 28, 2019

@esoft-adm  it is possible to export issues from one repo and import into another. With that said, you will need to convert the repos to git and then export issues from the hg repo and import the issues in the git repo. Here’s a doc with more info:

Tom Kane Atlassian Team Aug 28, 2019

@rajb245  Thank you for sharing your success story of migrating 5 repos from Mercurial to Git on Windows.

We know Mercurial use cases are very diverse and our user base can learn a lot from each other. One of the main reasons we set up this Community post is so that Mercurial users can share this kind of knowledge and be a resource for one another.

@Tom Kane I appreciate your position. Right now my main concern is that there is literally no way (either provided by Atlassian or a 3rd party tool) to preserve the discussions in pull requests.

When you delete everything come June 2020 you will be removing metadata that your users were unable to preserve despite their best efforts.

I will be happy to migrate, but Atlassian need to ensure that ALL data can be exported from your system. Right now that is not the case.


I will also add that converting everything to static HTML web pages (my suggestion) would not require maintaining mercurial infrastructure and would preserve all metadata.

Like # people like this

@Tom Kane Can you share any more of the statistics that fed into this decision, besides the Stack Overflow survey and the selections of new users? For instance, it'd be interesting to know what percentage of Bitbucket repo count / storage / MAU are attributable to Mercurial vs. Git.


> supporting Mercurial repos in read-only mode would require similar resources as continuing to support read/write repos.

This is at least, dishonest. Supporting only read-only repo saves you the work of maintaining extra features for mercurial, of ensuring the compatibility of new ones...

I perfectly agree that it still represent some work, but that exactly what we are paying you for: having the guarantee that our data is safe.

It's not some rogue hacker which will delete our data, but Atlassian itself...

> We have decided to provide a long deprecation window with this in mind [...]

A 10 months time frame is not a long deprecation window. 10 years is.

In the industry, we have to provide support for years, not months.

What if in 2 years, we have to provide a quick patch to an old software version, which we won't be able to rebuild, because the build system relies on the flawless availability of the source code?

Even if we've backed up our software to git repositories, it will take days if not weeks to fix the build system used back then. So long for the quick patch...


Don't be mistaken, I'm not groaning because I like mercurial and I want it back. On the contrary, I hate this piece of software, but I have to deal with it, because that's my job.

And it's Atlassian's job to the same, again, we're paying you for that.

Like # people like this

@Nicolas Carrier - "Hate" is a strong word.  If you hate Hg and Git about equally, or if you hate Git more than Hg, or if you hate all DVC software, then say no more. Otherwise, I for one would be glad to know what you find most hateful about Hg, or about Bitbucket's support for Hg before this announcement.  I would like to know because I am trying to represent a variety of viewpoints in some other context.

Well, my "hate" of hg is not really the point of my previous message and I don't want to start another VCS flame war here (hint, I really like git :) and wouldn't be able to live without a DVCS).

I made this point to emphasize that dropping hg or not isn't (in my situation at least), the key point, but rather the loss of data and the breakage of service continuity which at least paying customers should be protected against.

If you want to discuss more at length about the defects I consider that hg has, feel free to contact me by email: nicolas dot carrier at orolia dot com.

Difficult to see BitBucket keeping many customers, especially the paying ones after this decision which dumps a lot of work on customers with no support. You can't migrate repositories inplace, so you can't keep projects URLs. You can't migrate all the associated assets so you're faced with at least two steps per repository and still face data loss.

The decision won't be revoked but it's interesting that it was based upon a StackOverflow survey and not of users. I certainly don't remember being asked whether I would mind. Ie. this was about attracting new customers at all costs. This isn't the first time that Atlassian has made significant changes with apparent disregard for existing users, presumably expecting inertia to be sufficient reason for existing customers to stay.

There's also been no details about what the technical problems are. It's not that difficult to support multiple DVCS, which is why so many packages manage it. I've contributed my own patches to coveralls for hg support. Presumably the relevant developers were downsized or moved onto other jobs.

Then there's the irony that the software industry likes to tell us how keen it is about diversity and yet what we see, at least in terms of software, is a worrying trend towards monoculture. BitBucket used to offer users a choice, now it's joined the herd it's lost a key argument for choosing it.

Well, at least we've got a couple of months to figure where we're going to move to.

Like # people like this

The Bitbucket team arrived at our current Mercurial deprecation plan after lengthy research and thorough analysis.

BitBucket used hosting of OpenSource project as a part of BB's business strategy. But an OS-projects hoster has sense only if it hosts an OS-project as long as it can. It's normal when a hoster disappears completely (like BerliOS). It's normal when a hoster going out from this kind of business but continues to hold OS-projects for years (like Google Code). But your move can't be seen as "a normal" and raises questions about your reliability.

Atlassian's decision just tells "we're losing our role as a reliable hoster for OpenSource projects". Now we decided to remove public Hg repositories for OpenSource projects because we have no money to support them in read-only mode. But what will be tomorrow? Maybe you remove some project that has no commits for 6 months? Or has less than 10 active contributors?

Just look at the role OpenSource plays in today's world. And remember that BitBucket was an important building block in that. You are going to kill a lot of Hg-repos of OpenSource projects and invalidate a lot of references to those repos around the Internet. Lively projects, of course, will migrate to Git and/or to different hosting. But what about projects that are not actively developed? They'll just die. Atlassian will just kill them.

Regrettably, due to the infrastructure of the Bitbucket platform, solutions such as supporting Mercurial repos in read-only mode would require similar resources as continuing to support read/write repos.

Are you trying to say that BitBucket's software is just an unmanageable monolith that can't be split into actual version under active development and an older one that will receive just security fixes? Or that you have no experienced developers and/or devops engineers who can do that right way?

Anyway, your words make doubts in BitBucket reliability even stronger.

Like # people like this

Totally agree on the OpenSource argument. Aside from everything else, you were entrusted as the keeper of many OpenSource projects.  You **profited** from the goodwill this created in the community. That goodwill brought you paying users.

Your "research and analysis" that justified killing Mercurial is akin to the American car companies who, in the late 90-ies, decided to quantify the attractiveness of a car by measuring leg space, trunk space and the number of cup holders. According to their analysis customers should have loved the Pontiac Aztec. They missed the fact that humans get emotionally attached to stuff and no one could get emotionally attached to the Aztec, regardless of leg and trunk space.

As programmers, we are perhaps less human than the average person. Nonetheless we have emotions too, as well as notions of good and evil. Without Bitbucket Mercurial will die and with it , wonderful tools like TortoiseHg. Atlassian will be known as the killer of those. You will be perceived, for the next 10 years , as a company that did something very wrong. And I am not at all sure that the benefits of streamlining your infrastructure will be able to offset your bad karma.

Like # people like this

I selected bitbucket because of its Mercurial support. If that's gone, I may think of switching to GitHub.

Like colin-hurley likes this

Can't believe you guys are calling 9 months a "long deprecation window". I feel sorry for anyone who depended on BitBucket Mercurial hosting for work. Fortunately I don't; I can't imagine having to convert hundreds of repos full of issues, wikis, teams, external links that will become dead, in a span of under a year.

Like # people like this

I hope the Atlassian managers who have decided this will have a long, healthy life!

You know, like, ten months or so.


Like # people like this

bollox. but I'm glad that our ~500 devs can now move out from bitbucket.


Log in or Sign up to comment

Atlassian Community Events