Bitbucket Dropping Support For Mercurial

Bitbucket, once one of the largest Mercurial repository hosting sites, said Tuesday it plans to remove Mercurial features and repositories from its platform on June 1, 2020. In a blog post, Bitbucket wrote: As we surpass 10 million registered users on the platform, we're at a point in our growth where we are conducting a deeper evaluation of the market and how we can best support our users going forward. After much consideration, we've decided to remove Mercurial support from Bitbucket Cloud and its API. Bitbucket will stop letting users create new Mercurial repositories starting February 1, 2020, and start removing all the Mercurial repositories four months later. So you will want to backup your repositories and switch to a different platform in the coming months. A different user pointed out, "Another shitty aspect of bitbucket dropping mercurial support and deleting all the old repositories in 2020: all yt pull request discussions from before 2017 are going to be deleted. There's valuable context for how the code got written in those discussions." Several users have expressed their concerns over this decision. Sebastien Jodogne, CSO at Osimis, said, "This is an extremely concerning decision that endangers diversity in the computer science industry by pushing the de facto hegemony of git."

For those of you affected by this, you can consider a number of platforms including SourceForge to host and manage your repositories.

Used to be svn hegemony

[damaki]

If it were a closed source tool, it would probably be an evil hegemony but here, where is the harm? And before git, subversion was pretty much everywhere and I never heard it of it as an issue.
We could probably benefit from a more user friendly tool than uber complicated git, still git just works.

Re: Used to be svn hegemony

[phantomfive]

Source forge is kind of cool because it allows access to any repository through the client of your choice. Want to use SVN still? Great! Want to use Git? Also great. They both work.

Re:

[93 Escort Wagon]

But I want to use RCS...

Re: Used to be svn hegemony

[phantomfive]

Ugh. That heap? I wrote my own scripts that stashes changes in the MBR. It's a little awkward because I have to use fdisk to revise but the advantage is I can see changes without booting. It's my system don't knock it.

Re: Used to be svn hegemony

[sl3xd]

RCS isnâ(TM)t the end of the world. Itâ(TM)s been the foundation of a few version control systems that are better than CVS... I even wrote the code to export from one (companyâ(TM)s internal proprietary tool) to git.

Re:

[0100010001010011]

ClearCase and Jazz SCM depending on your industry.

Re: Used to be svn hegemony

[sl3xd]

Clearcase is version control for the S&M / Domination crowd.

When things go well, you need stitches.

When things go less well, you need a mass grave large enough to hold a genocide.

After that, I was willing to encode data by tearing off chunks of flesh from my body before Iâ(TM)d touch Jazz.

Guess that fits

[SuperKendall]

Bitbucket, once one of the largest Mercurial repository hosting sites, said Tuesday it plans to remove Mercurial features and repositories

Well, on the plus side, you have to admit the Mercurial guys really nailed the name.

Re:

[kahizonaki]

Wish I had mod points, this is hilarious. Gold.

Self Host

[brian.stinar]

This is a perfect example of the disadvantages associated with leaning too heavily on a cloud provider. We use Atlassian Cloud for Jira and Confluence, but self-host with BitBucket / Stash because we want some recourse if they make a decision we don't like, and I'd rather not have someone else in such direct control of our source code.

I used to tell my developers they could accomplish everything with command line tools, and there wasn't any advantage to using any Git graphical interface, but as I was saying

Re:Self Host

[Eravnrekaree]

Self hosting is the worst possible way to ensure that people have access to your software in the future. I strongly recommend against self hosting open source projects. Your best option is to mirror your work on as many sites as possible for redundancy. As far as future availability, self hosting by itself is the WORST CHOICE because the original developer is much more likely to forget about or to stop hosting their own repo. With self hosting the repos go down often without notice by their owner at the owners whims or due to the owner simply not paying the hosting bill or not turning on their server any more.

I disagree with bitbuckets decision and at least they should do the courtesy of converting the repos automatically to git if the owner of them does not, but at least we are getting some notice here where as with self hosting they tend to go down without notice .

Re:

[brian.stinar]

That depends on which people you want to have access. For open source software, I sort-of agree with you. I say sort-of, since your infinite mirroring policy leads to versioning problems, and doesn't specify which version is canonical. If there's a canonical source, someplace, then having a lot of copies of the code which refer to the cannon isn't a bad strategy.

This isn't a good idea when we are responsible for maintaining the code, and it's not open source.

Is it a problem if the original developer stops h

Re:

[Darinbob]

Yup, using the cloud is not so smart when you're trying to actually run a business. Sites go down, even Microsoft's Azure suddenly vanished for a few hours. Sure it happens when you're managing this locally but in that case you have someone you can actually blame and who feels pressure to get stuff running again. I was creating and experimenting in Azure DevOps when I got the message that I exceeded my licensed bandwidth and that I would be throttled; there's no contact person to discuss bugs or performa

Re:

[dryeo]

As a hobbyist, Bitbucket has been handy, especially a few years back when I on dial-up and even now when I only have a cell connection. Could host binaries besides the source, thus meeting licensing requirements and the master at home. Git projects I do host on a couple of clouds but back in the day, for Mercurial, Bitbucket was about it.
They did list a couple of ways to convert my Mercurial repositories to Git and also a small list of other Mercurial hosting sites, but it is still disappointing that it see

Re:

[angel'o'sphere]

I used to tell my developers they could accomplish everything with command line tools, and there wasn't any advantage to using any Git graphical interface, but as I was saying that I started choking on a snack accidentally left in my grey beard and was forced to be quite so I could finish my snack.
Yeah, and compared to bitbucket and the Jira / Git integration: that point of view is simply wrong.

I really enjoyed using Mercurial, but...

[Dutch Gun]

For my needs, Mercurial was great. I found the commands and overall workflow much more intuitive than git. But unfortunately, the network effect is a thing. Git's overwhelming popularity meant that it was always going to get first-class treatment in terms of tools and platform support. I simply had fewer options as a Mercurial user.

Even Visual Studio, of all things, was getting integrated git support. I bit the bullet and switched over my repositories. At the same time, I decided to move my private repositories to GitHub. I already had some open source projects there, and it just make sense to unify my workflow.

great tool, too long name?

[mmutka]

On the other hand, 'hg' is shorter to type than 'git'.

Re:

[jaklode]

In other word: git is 50% less effective.

Re:

[tdelaney]

Also, hg command lines are usually no longer than and often vastly shorter than the equivalent git ones.

You can have very complicated hg commands, but usually there's no equivalent in git e.g. revsets [mercurial-scm.org] (although gitbase gitql [github.com] and cloudson gitql [github.com] look like they're steps in that direction).

Re:

[mattyj]

Times change. It's about a 20 year cycle. I've been in the tools admin game for over two decades and have gone through rcs->cvs->svn->git, with Clearcase and Perforce thrown in there. In another 10 years we'll be switching to whatever comes after git.

The way these things happen is new companies adopt whatever the new/standard thing is and it grows from there. If you're in a business where you have acquisitions, across the board you're importing git repos these days.

As a fan/historian of source cont

Re:

[loonycyborg]

Never saw any point in bitbucket as anything other than proving ground for hg. For anything else you're better off with github or sourceforge or gitlab. Hope they'll get appropriate outcome [tvtropes.org] for this move.

Re:

[dryeo]

IIRC, github and gitlab weren't around and sourceforge was crap and didn't support Mercurial back in the day.

Delete? Why not convert?

[Gravis Zero]

I'm not fan of mercurial but why are they deleting repositories instead of simply migrating them to git? Serious question considering scripts to do this very thing already exist.

Re:

[Phillip2]

This is making a statement that the new repository (i.e. the git one) is a "real" repository. Which it might not be if you are the developer and want to continue to use hg.

Basically, it's something that only the developers should do, not the hosting software. It's easy enough to do as you say.

Re:

[Eravnrekaree]

I disagree. The auto converted repos could have a notice placed on them that they were autoconverted, not by the developer, this solves any problem with people thinking that it is the developers original repo rather than one which was converted.

Also many repos are no longer maintained by their developer but many contain code that is needed or of use by others, this is why an automatic conversion is important. Some of the code may be useful to developers in the future and should be preserved for that purpose

Re:

[dryeo]

There's also the issue tracker that is going away. Not so easy to migrate.

Re:

[Chris Mattern]

I'm not fan of mercurial but why are they deleting repositories instead of simply migrating them to git?

Bitbucket is apparently not interested in doing work repository owners can do for themselves, even if they're the ones making the work necessary.

So after reading the summary

[bobstreo]

I guess we'll be seeing all kinds of ads at the top of the /, articles about migrating your Mercurial repositories to sourceforge...

Yeah but think of the benefits of Mercurial!

[mgrinshpon]

Here's a great blogpost about why we should choose Mercurial: https://www.atlassian.com/blog... [atlassian.com]

Re:

[Jastiv]

That was written in 2012 so it is way to old to use in deciding what version control system to use today.

Re:

[anarcobra]

Here's a great blogpost about why we should choose Git: https://www.atlassian.com/blog/git/git-vs-mercurial-why-git

I never used Mercurial or Bitbucket for my project

[Jastiv]

I really hated to move off cvs even though in some respects it was straight up awful (ie, don't poop the sandbox). I guess I was very reluctant to, because it would mean I would have to learn some new tool. Now, I enjoy just doing testing in the git sandbox and not having all those folders all over. On the other hand, git doesn't necessarily handle binary assets in the best way. I moved to git, not because it was good, but because I knew I could have it hosted anywhere cause everyone supported it. Plus, I

Re:

[laffer1]

Yeah, i did the cvs to subversion conversion for my BSD project and I agree that there are things about CVS that are missed. I'm currently downgrading to git so that younger developers have a chance to contribute. So few are willing to learn SVN or any other VCS now.

Git is really good for some types of projects, but they never did fix the scaling problem. LFS isn't really a solution.

Re:

[jrumney]

CVS to SVN was a downgrade, but git brings back true branches and tags, which was the functionality lost in the CVS -> svn conversion. And CVS really didn't handle large binary files well either, even SVN is not really handling them any better than git+LFS.

Re:

[angel'o'sphere]

All of them handle large binary files just fine.
The only "problem" is: diffs are meaningless and merges etc. not possible (why would they?)
Oh, you forgot to to tell the system that you are in fact checking in a binary file and CRLF versus LF or CR conversions made it useless?

Re:

[angel'o'sphere]

SVN was much better than CVS due to its atomic commit and singel revision number per commit.
However it is bug ridden, till today.
Has no .svnignore file which is a pain in the ass in real software projects, especially if Eclipse e.g. considers to simply ignore the "ignore attribute" set by tourtoise and even tries forced commits because it thinks it is right ...
The mina draw back of SVN was 20 years ago: its name. What you think how hard it was to convince managers that a tool called subversion with a comman

Why not auto convert it all to git?

[Eravnrekaree]

Why not convert, if not the history, at least the main branches of the mercurial repositories to git, instead of deleting the code altogether, so the code can be preserved?

Re:

[dryeo]

Not just the code. Binaries, issue tracker, perhaps a wiki, though at least that is a repository and easier to move if anyone is interested.

Integrity

[Netdoctor]

Hey Guys...when you mention your own product in a news article as an editorial comment...you kinda lose journalistic integrity...

I'm still holding out a light for this site, so c'mon...

Re:

[dryeo]

Sadly Sourceforge is one of the few Mercurial repositories left. There's a couple more that Bitbucket linked in their email, but all the others are for free software only, which I assume means GPL compatible.