One thing is to discontinue support for Mercurial. That's your decision, many people will wish you hadn't but that's fine.
But deleting our repositories? That is something completely different.
You are a source control provider. We come to you and trust you not to... delete our code. As a source control provider the very least you can provide is... not delete our code. And then you... delete it?
How on earth do you expect users to trust you after this?
It's been a pain moving all my repos across, but I decided on converting to git, and migrating to GitLab in the end. I'll eventually wind down my bitbucket repos and say "goodbye, 'twas nice using your service at one point".
I generally have prefered hg to git, at least in terms of hg as a more focused vcs with fewer crazy options... but one really annoying thing about hg is the weird multiple branch heads thing. (Shame bazaar never took off that much, as it seemed even more intuitive.)
Google Code offered a migration tool to your service when they sunsetted. You should provide a conversion tool. This is pretty half-assed on your part otherwise
I've been a Bitbucket user since 2012. I'd be happy to stay a Bitbucket user, but if they are just going to delete all of my Mercurial repos, and aren't providing an easy way to migrate them to git automatically, I can't see any reason why I should keep using Bitbucket. If they are going to force me to go to a bunch of pain by hand, I don't see why I wouldn't just move everything to Github or Gitlab, where I'm more confident that they won't decide to just blow away a bunch of my repositories. Is anyone from Bitbucket listening? Seems like they aren't, since every major project I've worked on seems to have abandoned Bitbucket in favor of Github or Gitlab due to the general unreliability of service.
I ended up making a script to migrate all repos (hg or git) from Bitbucket to git and GitHub. Its most severe limitation is that it won't migrate issues, but perhaps somebody else can add that?
Can we get some support in migrating 50+ repositories?
I'm familiar with bash scripting and GIT, but I'm stuck on 2 things:
- getting a list of all Mercurial repositories in the team from the command line
- creating a new team GIT repository from the command line
We tried to work with the API but run into issues with authentication and CSRF. A command line interface (like the old Python bitbucket-cli) should be a great solution!
The product is not very good promoted, but I was using it for a couple of weeks on one project and I would say I definitely like it! Here is a short review:
Pros
Support several version systems, including mercurial, git, subversion and few more I never heard about!
Free for 5 users. For 5+ it costs $19/year! (less expensive then BitBucket)
Allows to group Repositories in projects. Each project has it's own Wiki and Issue tracker
Pull request and code review very similar to BitBucket experience
Support integration with a ton of external services, including Jira, Slack, Trello, etc
Cons
No download section (useful for upload binaries). A workaround is to have a dedicated Wiki page and submit binaries as attachment
You can't move repositories between projects
No public repositories (not suitable for Open Source)
An interesting fact is that TeamHib was lunched in 2017! It looks like it gets updated a couple of times a year. This sounds like an irony, while ones are dropping support for "unpopular mercurial", others lunch new products based on it and making a business.
Just as an FYI, we (the Perforce Helix TeamHub team) are in the process of adding code search support for Mercurial and will then be adding the ability to make code edits as well as create branches directly from the web browser like we currently support for Git. Mercurial is a first class citizen with Helix TeamHub!
@Bradbury Hart - I suppose (follow-up to tukanos), public repos have to be a must for Helix Hub in order to consider it as common-case replacement of BB.
And, please, don't ignore fresh and usable addition to Mercurial - add server-side support of evolve in your HG (it's sometimes more important, than bells&whistles in webUI), just because nobody still offer it as public feature and it's really must-have thing
Thanks for the feedback. That is always very helpful and welcome. Brent Schiestl ( bschiestl@perforce.com ) is the Product Manager that owns Helix TeamHub. Please feel free to reach out to him and he can share where we are going with the product and talk further with you to understand you use cases around the features you are requesting.
Congrats, Atlassian, you are now a prime example for all those that don't put a single trust into cloud companies, especially if their PR agents keep on writing text like "Mercurial will always have a special place in Bitbucket's history".
Not only do you want to delete repos instead of putting them on a read-only back-burner, like decent companies that went out of this business did in the past. No, you don't even help your former users with this painful migration. I am pretty sure you will do so with Git repos as well one day.
Just in case you don't know so already, this sends a clear message: never, ever trust Atlassian with your code.
You might be interested in rerefcommit, which allows you to translate commit references from hg to git. The Example section of the README shows you how to do this with Bitbucket issue dumps.
However, note the described limitations of that example. To convert bigger repositories, a dedicated Bitbucket conversion tool which makes use of the general-purpose rerefcommit library should provide better results. But I'm not interested in writing such a tool.
Update 2020/01/03: the JSON translation functionality, which can be used for the translation of the issue dumps, has moved to rerefcommitjson.
It is supposed to be converted to git and then git should be used? What's about sticking with Mercurial and using hg-git plugin
I did manually a different thing, I generated a git repository, used the latest hg-git plugin + a patch which makes the treatment of named branches easier (topics are not supported). Then I pushed and run some test with other mercurial users, using the same configuration and it worked well.
so the question is could you tool also be used for the conversion, but sticking with mercurial and the hg-git plugin. thanks Uwe Brauer
I've added a Wiki page to the project with an FAQ which I hope answers your questions.
Basically my tool is completely non-destructive, it creates a new `-git` clone of your repository, so you can try it out and use whatever tools you like afterwards.
531 comments