It's very unfortunate. Bitbucket is one of the only providers of quality software project management tools that explicitly support Mercurial out of the box. We use both Mercurial and Git in our work, but the lack of Mercurial support has us compelled to use other solutions from other providers. You can imagine how pleasant the integration and compatilibity issues that crop up are with this kind of compromise.

Thank you, got it. So sad...

It may be marked Resolved, but the Resolution is "Answered" and the answer a year ago was "No, not ever."  Alas.

One could only hope!

It seems that this issue has been changed to resolved, I wonder whether it will be added to the coming version of Bitbucket Server? Thanks~

We're using both git and mercurial. And it is really sad that there is no mercurial support... We will buy bitbucket server when it will support mercurial....

p.s. we're users of Jira software

We're confident that the improvements we have planned for Git-based development in Bitbucket Server will unleash the greatest overall potential in software teams around the world, and we look forward to supporting you.

And yet, in this announcement, you're saying you are not supporting our needs.

Hi everyone,

Firstly, thanks for your feedback, passion and advocacy for this suggestion. Please accept my apologies for allowing this issue to remain open for some time without clear direction from Atlassian.

We would love to support the availability of choices when it comes to DVCS-based development in Bitbucket Server. However, we have decided that the engineering cost of adding and maintaining Mercurial support is ultimately the wrong direction to take the product. While it is heartening to see recent developments in Mercurial as an SCM, we have not seen signs of a positive market shift that would justify an investment for Bitbucket Server, especially given strong demand from existing customers for more capabilities based on Git.

A number of people have offered approaches to make this suggestion a reality for Bitbucket Server, and we've explored and discussed them all. Ultimately, we feel that any commitment to Mercurial would need to be a full commitment; anything else defers future disappointment, as a second-class solution leads to frustration and regret.

While Bitbucket Server and Bitbucket Cloud offer the same primary code collaboration features, they do have different origins, allowing them to optimize for the needs of their subtly different customer bases. Bitbucket Cloud has a strong foundation as a Mercurial hosting product and has a loyal following that it will continue to support while also investing in a range of other improvements. I reiterate my past recommendations to consider Bitbucket Cloud for Mercurial hosting if the choice between DVCS options is what is most important to you.

So if we are not going to implement this feature in Bitbucket Server, what are we doing instead? We remain committed to helping software teams deliver high quality software faster in an increasingly competitive and changing world. We believe that great developer tools are a key element of modern software development in the hands of good teams with smart processes. To that end, we've made improvements already and are planning to work in the following areas that help with problems teams face now:

• scaling to ever larger numbers of users and CI/CD load - security, performance and manageability at scale is baked into everything we do
• seamless workflow integration between Atlassian and other leading products, bringing together the combined power of best of breed tools
• innovations that increase team consistency and developer productivity, and reduce complexity despite an ever evolving technology landscape

Thank you again for your long-standing interest and feedback on this issue. We're confident that the improvements we have planned for Git-based development in Bitbucket Server will unleash the greatest overall potential in software teams around the world, and we look forward to supporting you.

If you have any questions or concerns feel free to contact me directly.

Cheers,
Roger Barnes
Principal Product Management - Bitbucket Server
rbarnes |at| atlassian |dot| com

Quite a few teams in my company are using Mercurial. We just setup our On-Prem Bitbucket server, supporting of Mercurial will make the life much easier for our Mercurial teams to get benefit from Bitbucket server.

My company (2200 devs) uses Mercurial on Windows. And, as all other people here is very interested to have a behind the firewall solution supporting Mercurial. Hoping this will come as soon as possible.

My company is looking for such a tool too (Mercurial support)

Other companies are now filling the void Atlassian is leaving with their crumbling Mercurial support: https://deveo.com/mercurial-repository-hosting/

I met the guys from Deveo at the GOTO conference last autumn and they seem to be quite happy with their Mercurial hosting.

My company is looking for such a tool

Our company started using Mercurial and used it for many years. We only seriously considered switching away from Mercurial because the lack of support for Mercurial in Bitbucket. If we could have support for Mercurial, it would greatly simplify our long term support work we need to do for our older products, and give teams the opportunity to use whichever tools they prefer.

@jens How about just doing it as a minimalistic Labs feature?

That would be great. Mercurial was also our preferred VCS, but we were forced to GIT due to the lacking hg support of Stash (Bitbucket Server).

@jens How about just doing it as a minimalistic Labs feature?, gauge response, learn a few things and see what happens.

Worst case, you get some Mercurial folk into a system where Git is the first-class citizen and they get a chance to also try it out. You also get to improve Bitbucket Server's architecture in the process and future-proof it. This would also be useful for companies where islands of Mercurial users could be switched over to Git.

You can also open source it as you guys do for many things (http://atlassian.bitbucket.org/), and let the community do part of the heavy lifting.

Bitbucket Server is becoming very scalable, with mirrors now supporting Git LFS, I think the only thing needed is getting the point to enabling mirrors to be automatically 1:1, and then all you need is distributed load balancing to have a globally scalable infrastructure. The point being that you don't need to duplicate efforts long-term. The previous ones are, after all, enterprise features.

As a fan of Atlassian tools, I decided to jump to Git, have not gone back, but I am definitely not happier than I was with Mercurial and sorely miss it.
I used to be a Mercurial guy, but have been disappointed the Mercurial dev community has not focused on the Evolve extension, which would almost automatically make it superior to Git.

I think, hosting a Mercurial repo, providing braches, tags and the commit history would be enough for a first version. So we can use Bitbucket Server with Mercurial.

@Ulrich, we certainly considered options in between. However, they come with a whole lot of others issues around managing expectations on what functionality is available and this feature request would quickly be replaced by "Support pull requests for Mercurial". That being said, it's certainly an option if we can think about how to work around the issues.

You talk about the overhead of implementing a feature for two SCMs but tell me how it's better to implement it in two products?

onigoetz656105293, Elizabeth essentially answered your question already. The benefits we get from developing for a specific platform (Cloud vs Server) have so far out-weighted the effort of duplicating features. We've evaluated taking Bitbucket Cloud to Server before we started writing Stash (aka Bitbucket Server today) and later explored the option to take Stash into the Cloud. Neither option was workable for a number of reasons.

@onigoetz Because the two codebases are radically different. The Server edition codebase is all Java/JVM. But the Cloud hosted edition is a lot of everything, right down to the front end being a Django application. Merging the two would take a ton of effort, and would result in a lot of job shifting and layoffs more than likely.

@jschumacher Thanks for the update, it's much appreciated.

While I understand your argument of focusing on Git because it's the current leader, that's true.

But it's not as if you never supported Mercurial, your Cloud solution supports it.
And it's very confusing to hear that a hosted version supports "both combustion engine and electrical engines" and you get only the "electrical engine"

So your Server offering is MORE expensive while providing LESS core features.

I'm sure you already thought about what I'm going to propose, but I will try it anyway:
Currently, you have two codebases: Bitbucket Cloud and Bitbucket Server.
Why not add Mercurial support to Bitbucket Server and deploy that to the Cloud ?

In the end, that's the same product for the outside world, it doesn't make any sense to keep the separation, you have two dev teams doing the same product twice.

You talk about the overhead of implementing a feature for two SCMs but tell me how it's better to implement it in two products ?

We currently have a big installation of Jira, Confluence, Fe/Cru and more than 1500 Mercurial repositories. Bitbucket Server would be a really nice integration into this mix for us.

@jschumacher: Thank you for your explanation. I know that integrating Mercurial is not as easy as some little button at the top of the page displaying some message ... I am myself a software developer and architect. But as you said, I knew, that some of your developers would support Mercurial as well and I hoped, that some did already a prototype .
So, why not only thinking black-white, but a kind a grey? Focus on GIT, perhaps 80% of the time, and provide the many people here wanting to use Mercurial a basic set of functionality. I think, hosting a Mercurial repo, providing braches, tags and the commit history would be enough for a first version. So we can use Bitbucket Server with Mercurial. And then the progress can go smoothly time after time, but we can work with the product.
Couldn't this be a way to satisfy both 'sides'? You do not need to investigate much resources... and the 495 people here will be happy as well.

Sure, we could provide more frequent updates, but these would be meaningless and spam hundreds of watchers with email notifications.

That doesn't make any sense. People watching this issue expect to hear about updates, so it should be the preferred way to communicate if something small changes on this issue. If it's happening very slowly and with uncertainty for the future, it's still some form of progress, so why not comment on this issue more frequently (like every 2-3 months or so)...

Aside from that Atlassian has a rather talkative blog as well as a regular newsletter (for more official stuff). I can't remember having seen anything about Mercurial there lately.

For everyone still looking for an immediate self-hosting solution, if you are considering RhodeCode, please also have a look at Kallithea as well. It has been forked from RhodeCode over GPL violations and although progress is slow, it has quite an active community. Not as polished as an Atlassian product and a bit quirky on the UI but still the best bet when it comes to Mercurial SCM hosting. It also does Git if you need it.

Thanks for your comments. I would like to address a number of points made in this thread. After all, we pride ourselves of being an open company.

... it seems like no one on the Atlassian staff pays attention to these issues.... this will just fall on deaf ears.

We do read every single comment. We don't respond to every single comment, that's simply not feasible at our scale. We try to provide frequent and meaningful updates on popular issues, but at times the gap between these updates becomes larger than intended.

However, "no update" simply means that nothing has changed since the last comment. Sure, we could provide more frequent updates, but these would be meaningless and spam hundreds of watchers with email notifications. Finding the right level of communication on a public issue tracker is extremely difficult and something we've been struggling with for a while. This topic alone deserves a whole separate blog post.

We are currently at 495 votes for this topic... every other feature with such high votes would be implemented in the upcoming release

It's important to understand that supporting Mercurial is not like any other feature. If I had to think about an analogy, it's like asking Tesla to support combustion engines. It's not just a feature, like ludicrous mode, but a significant change that has to work with all aspects of the car. We know exactly how much work is involved in supporting Git and Mercurial at the same time, we do it for Bitbucket Cloud. It's not only the initial investment that's significant, but also the ongoing maintenance and overhead for every new feature we add.

Could we do it? Of course. But it is a trade-off between building an average product that works for both, Git and Mercurial, or a great product that works only for Git at first.

You're waiting for some shift in the broader market in favor of Mercurial in order to commit resources to this?

It's one of many factors that influences our decision. If we saw a huge increase in Mercurial adoption, it would certainly incentivise us to re-consider the priority of this issue. Supporting Mercurial would expand our market, but come at a cost for our existing customers, who are Git users.

It's not that we don't want to provide Mercurial support. A number of our engineers are very passionate about it. But like every company in the world we have a limited number of people and right now we are focusing on building the best possible product for Git users.

If Atlassian really doesn't want to show love for Mercurial anymore they should just 1) close this issue as "Won't Fix" and be done with it and

We could close this issue, but what will you say when we implement Mercurial support in 18 months? Atlassian lied to us? Fact is that we haven't ruled it out entirely. We even had a prototype running internally supporting the basic hosting operations... remember when I said above that some of our engineers are really passionate about it too?

That being said, we can usually provide a good indication for the foreseeable future and right now we don't have plans to add Mercurial support in the next 12 months.

A personal note
It's difficult to write updates on issues that have been around for a while and haven't been implemented for one reason or another. People are frustrated because we don't deliver something that seems so obvious, so simple. Acknowledging the situation and the frustration, which I can relate to, is a difficult thing to do in writing. A quick update like "We won't be working on this for the next 12 months" often leads to even more frustration. Providing more context can help, but also doesn't alleviate everyones concerns since different people have different priorities. Lastly, finding the right tone is important... so writing a quick update can easily take up an hour or two. Written communication is difficult.

Just like at your work, people come in every day with the intention to do their best work and build the best possible product. It's easy to blame "Atlassian", I probably do the same with other companies if I'm completely honest with myself. But it's important to remember that there are individuals, humans behind that company facade. In most cases they are not evil and it's important to seek to understand first, even if one doesn't agree with the decisions.

Thank you,
Jens

"Why not just come clean and close the ticket?"

^ this

.. and with that I am unsubscribing from the issue. I've been subscribed for two years. Weird stuff, keeping this open like this. Weird stuff.

We're not moving to git, but we've already started moving away from Atlassian. We're actively evaluating RhodeCode and other similar products; we've made the decision to move away from Crucible and FishEye (how many years have they been holding off supporting bookmarks??). I can see after that a desire to move away from TeamCity too. And, the grumblings over JIRA and Confluence are low key, but pretty constant....

(The other interesting point is we were told flat out that there is absolutely no way Atlassian would even take our money to give us more than the 2GB size limit on the repos...)

Is this really right? You're waiting for some shift in the broader market in favor of Mercurial in order to commit resources to this?

If so - it sounds like you've tacitly made the decision. Why not just come clean and close the ticket?

If and when you do close the ticket, we'll have to face moving to git to get the features we want. Yes it's conceptually a small shift but practically an expensive one - years of tooling and mind set - and once you force this level of change on us, we will of course be reexamining our commitment to the Atlassian ecosystem.

Keeping the ticket open knowing you're doing nothing seems transparently manipulative.

If Atlassian really doesn't want to show love for Mercurial anymore they should just 1) close this issue as "Won't Fix" and be done with it and 2) write a press release on their blog saying they are abandoning Mercurial because they "see the writing on the wall."

Although, since it seems like no one on the Atlassian staff pays attention to these issues.... this will just fall on deaf ears.

sigh

At this point it we have been asking for this for four years.

The interesting part is that I started using Hg in the first place because of Atlassian whom was brought to my attention by Joe Nuxoll

Frankly given the experience with this issue - I no longer consider Atlassian to be a thought-leader in the industry.

Instead the approach seems to be to push & cajole everyone to Follow the Herd. So why would I even bother with BitBucket & not follow the herd all the way to GitHub? Especially if it is all about "marketshare" after all?

The answer is clear: I don't WANT to.
Neither does anyone else on this list.
We all have a list of axes to grind with regards to git, GitHub and the community surrounding them.

By pointing out that you have already made the change you are humble-bragging and virtue-signalling your wisdom for reading the writing on the wall. [golf clap]

What is the POINT of nay-saying on this thread? If you're not interested - then unsubscribe.

The inability to commit one way or another is what has allowed this to go on so long. If you insist on the customers making the choice on their own - they will not choose you.

Does this come off as salty? Let that indicate my frustration level. The only version control system that Linus Torvalds himself fails to regularly dis - the only one that consistently got honorable mention from him - was Mercurial. But let's forget everything that it does right & ignore all of the warts that come with git because Atlassian is too frugal with their development dollars and lost the war by default.

@chrisdrobison:

If Mercurial is so close to Git, why not just move Git then and be done with this thread?

I did not say, they are equal... yes, you can do some more things with GIT, which you cannot do with Mercurial, but exaclty this makes Mercurial the choice in many companies. You can rewrite the whole history of a GIT repository, a nightmare to auditing. And the several merge strategies in combination with the 'rebase' can causes much harm... and so on...
Did you really mean, that 495 people should better choose another product? I am sure, there are many real customers and I don't think, this is the right way, if you want to have a clean product suite for development process like integration with JIRA, Bamboo, Confluence and so on...

And, as @jmsachs said: Atlassian bought BitBucket, so Atlassian has already everything which you need for an integration into Stash (aehm, Bitbucket Server). So I and many others don't understand, we this topic has no progress, when it has so much impact on so many people...

Would it be bad to say that Atlassian is the new Google? I.e. they acquire technology/products and then let them rot a horrible death (e.g. Nest.)

[Roger Barnes]
David Snowdon, at this stage we still haven't seen signs that the SCM market is shifting, nor that it would shift, in favour of us diverting effort toward Mercurial support in Bitbucket Server. While I'm not one to say never, such a shift doesn't appear to be likely.

You know, this makes me very angry. Prior to 2010 there were two major cloud-hosting services: Github for Git, and Bitbucket for Hg. Then Atlassian bought Bitbucket. Github made continuous UI improvements that helped Git to dominate the market. Honestly I see very little that's different from Bitbucket in 2010 to Bitbucket today. In 2011 Atlassian added Git support to Bitbucket. Sometime in the last year or two, the marketing material for Bitbucket (the cloud version at least; I really wish you hadn't renamed Stash to Bitbucket Server) has shifted from "We offer Mercurial and Git hosting" to "We offer Git hosting" with a little asterisk hidden in a few places that says that Bitbucket supports Mercurial also.

Come off it, Atlassian! You're a big part of the reason why Git has come to dominate and Mercurial hasn't. So please don't tell us that the reason for not supporting Mercurial is because you see no signs the SCM market is shifting, when you've helped cause this issue.

I would much rather use Mercurial because it's simpler, and if we do end up using Git, it is not because we want to but because we have no other practical choice.

@ulrich @chrisdrobison, yeah, we moved to RhodeCode since Atlassian has dropped the ball too many times.

@ulrich If Mercurial is so close to Git, why not just move Git then and be done with this thread? We used to be on Mercurial and saw the writing on the wall and moved to Git. Was it painful, yes. But in my mind, Git is the clear winner in the DVCS world in terms of market share. I can't say there was one thing Mercurial had that Git can't do in some form. To everyone, there are other products out there that provide Mercurial support, why keep harping on this thread?

Dear Atlassian Team,

do you really need a shifting? Wouldn't it be better to support just the two most wide-spread version control systems? We are currently at 495 votes for this topic... every other feature with such high votes would be implemented in the upcoming release, but here, no progress is shown. That's really disappointing...
I don't think, that Mercurial is such different from GIT, the implementation of supporting Mercurial could not be rocket science. So please, rethink your decision and think at the 495 votes for this topic...

daves, at this stage we still haven't seen signs that the SCM market is shifting, nor that it would shift, in favour of us diverting effort toward Mercurial support in Bitbucket Server. While I'm not one to say never, such a shift doesn't appear to be likely.

Dear Atlassian,

Could you please give us some idea of whether you'll ever support mercurial? If not, we are going to have to either:
a) go to a significant effort to migrate away from our preferred version control system (mercurial by far);
b) choose a different repo management system with suckier integrations with your other tools (for us, JIRA, bamboo);
c) migrate away from Atlassian tools altogether to a different set of tools which do provide these integrations (TeamCity).

None of these options are fun.

Dave.

I agree with this remark: We are waiting for a huge time now... and they appear to refuse to move on.

What strike me (among other things), is the last Atlassian monthly newsletter was about augmenting revenue by improving user satisfaction...

... Maybe Attlassian (hidden) policy is to keep a large enough set of angry users to make sure the buzz should goes on ???

Cheers,

At the risk of angering the 277 people currently watching this issue with a possibly unneeded email - The last official update appears to be from September of 2015. As of now, this JIRA issue is the most voted on BSERV issue, including closed issues. Are there any updates from Atlassian on if this feature is being worked on or if it is on any roadmaps?

Dear Atlassian, please take into account that you are a strong market influence, especially in the enterprise world, so your decision also influences Mercurial usage.

Because of this we have to only offer git support internally to our employees and migrate or forget about our Mercurial users.

Please stop commenting on this issue to express your support. That is what the VOTE button is for! We get the fact that you care, but you are spamming hundreds of people and your point has already been made 100 times. Please vote and wait patiently.

I recognize that there's a certain movement that 'Git is the future' but there's advantages / disadvantages to multiple DVCS approaches. What makes the saddest is that Bryan Turner basically told us that "We did 90% of the work to make multiple VCS support, but we're not gonna do the last 10% which prevents even the community from filling in the gaps."

I cannot fathom why this decision could be made... Sure if it doesn't make business sense to spend the time developing the plugin surely spending a fraction of the time to pay the technical debt so that the community at least could make the product more useful is. This is the primary function of the tool, hosting repositories and the thing Atlassian is known for is Mercurial first! Please reconsider.

Agree with previous comments – we have teams who can use stash and those of us with mercurial repositories are using sub-par tools.

This is blocking my migration as well. My company runs both HG and GIT repos. I actually installed and set up the solution before realizing that HG support was missing. Shame to see this sitting here for this long.

+1 Mercurial support.

Given your (hopefully temporary) stance, any work-arounds would be welcome in the interim.

@jason.huggins, Thanks, but yes, this issue is specifically about having Stash, or BitBucket Server, support Mercurial, for those of us who want the pull request, etc. features without going to Git or the cloud.

@JonStory: Sorry, I joined this thread based on my experience in Bitbucket hosted which also lacks Hg support for Stash.
Besides, I wasn't actually suggesting Bitbucket Server, its easy enough to clone your own intermediate repository in-house for replication without the bloat of a full fledged server.
Saves you $16,000 in an enterprise if that's all you are using it for.

Our workflow depends on more than just the code hosting portion of BitBucket. We use the Pull Request features, JIRA integration, etc. All of which would not be usable from an in-house repository.

+1 to what @JonStory said

@JasonHuggins - a replica of your repository in house? What a fantastic idea. Truly revolutionary.

Now, if only there was something exactly like BitBucket that we could host in-house. We could call it something like BitBucket server, and use it locally.

Perhaps it could support both Git and Mercurial, even, so that we could store all our repositories in it, just like BitBucket.

That's precisely the point of this entire feature request.... we want an in house BitBucket for Mercurial.

@OwenConti I ran into the same issue. We had servers that would check bitbucket periodically if there was an update, when the service went down we would stall.
I built in some resiliency to gracefully continue if bitbucket was down, continue operation, and try again next time.

Also, you could also create a replica of your repository in-house and pull from there to reduce latency and lower connectivity issues.

And again today

When your entire application depends on the ability to access your code, having a cloud solution that often dies is not an option.

This is why we want an onpremise solution. Your website is suffering a 'major outage' at the moment.

I was sorely disappointed to learn that only BitBucket in the Cloud currently supports both Git and Mercurial. It's a deal-breaker and cloud is not an option for reasons similar to previous posters'.

This response of "If you want Hg, try BitBucket in the cloud" somewhat misses the point.... we aren't using BitBucket server for entertainment purposes, we're using it because an on-site solution is the one we require. If using the cloud was an option, do you think we would be looking for a self-hosted solution?

"In fact, I'd very much recommend it to those wanting to host Mercurial repos and I'd love to hear of any barriers that prevent you from doing so."

First hurdle is NDA's. You're a third party.

Second hurdle is BitBucket is updated and maintained on your schedule not our schedule.
We got burned by FogBugz; they don't sell "For Your Server" anymore so they got cancelled.

Third hurdle is the security team is not comfortable sharing the same server located on-premise never-mind a cloud solution. (They get their own system.)

Maybe if such abstraction was available Atlassian could just let the community sort out the demand for Mercurial and other SCMs.

Maybe there could even be a portion of the audience willing to write something for subversion so that their company can have a smoother migration path towards a DVCS.

onigoetz656105293

There's nothing in our policies that would prevent one from writing a Mercurial plugin for Bitbucket Server, or a plugin supporting any other SCM for that matter. The real issue with writing such a plugin is simply that the system wouldn't work with it. While we do have an Scm abstraction in Bitbucket Server, it isn't complete and some parts of the application do not honor it; they use Git commands explicitly. That means having Mercurial repositories in the system would lead to obscure failures. And those failures would be impossible to correct, given that the community can only write plugins using the APIs and SPIs we expose; they can't make changes to the host application (and we do not accept patches submitted for any of the code in Bitbucket Server, for various reasons).

Until Bitbucket Server has support for a second SCM, essentially forcing the application to fully honor the abstraction that's in place, it's not really possible for any party other than Atlassian to create an SCM implementation.

Best regards,
Bryan Turner
Atlassian Bitbucket

[...] using Mercurial in the cloud. [...] I'd love to hear of any barriers that prevent you from doing so.

In case it's not obvious, it's for the same reason why not all JIRA or Confluence installations are hosted in the cloud: Self-hosting gives you more control over data security and availability. In fact, if you are working on projects which may not be disclosed to third parties, you are unable to store them "in the cloud". Cloud DVCS storage is fine for open source projects but not for proprietary software or fixing security related issues.

we will continue to monitor the DVCS market for developments

Okay, so maybe the next DVCS that comes around will be supported then. It's true that Mercurial has been loosing a lot of its market share to Git but that's primarily for a lack of support from tool developers like Atlassian. As others have been highlighting, this issue is 3 1/2 years old. Since then, Git has continued to gain share mainly because no one seemed very interested in developing a good code repository management tool. We still use Mercurial for all our internal projects (still hosted by an old RhodeCode release) but if development involves external parties, we feel forced to use Git instead. Having been a Mercurial user since ~2007, I can only say that while Git has a few advantages, especially the CLI is a nightmare to use compared to Mercurial. And it somehow feels more fragile, too - you need to know a lot about Git's internals to be able to use it correctly. With Mercurial you did not have to worry much about internals, you could just use it. So, yet again, the second best technology won.