If you are a Mercurial user that still need a plan for hosting their Mercurial repository, I would like to point out the Heptapod option. Heptapod is a friendly fork of GitLab that supports Mercurial.The project has first class support for Bitbucket import.
Otherwise, a commercial instance is about to be launched.If you are in urgent need of Mercurial hosting, get in touch (via the form), we are looking for more people to join the alpha phase before we open registration to the general public.
I think Atlassian should have come up with an "archive" solution instead of "delete" just so people have access to download the unsupported repos. But the move does make sense given the numbers.
I'm happy to announce that we’re rolling out support for cloud hosting of our on-premise RhodeCode platform! RhodeCode is a multi VCS source code repository management platform that had native Mercurial support from the beginning. We offer most of the Mercurial features like Large Files, Bookmarks, Pull-requests, Phases, etc. We're running usually on the latest Mercurial version too.
If you’re looking for a new home to host your Mercurial repositories, please let us know by submitting a request via https://rhodecode.com/try-rhodecode page.
You can set the repository to private in the github importer if you wish. If you still want to stay with bitbucket, you can then clone the git repository from github and reimport in to bitbucket.
No idea what happens to issues, wiki etc within bitbucket (they aren't imported by github). I would think and hope that Atlassian isn't removing entire projects, and that issues and wiki will stay in place - but I don't work for Atlassian, and I don't think they've clearly stated one way or the other.
Atlassian should really explicitly address what is going to happen to issues/wikis etc when the mercurial repositories are deleted.
Fair warning - since the wiki of a repository is also an hg repository, it is likely you will lose any wiki content if you don't also clone and convert the wiki repository.
Also, exporting the repository to git, and reimporting it, it appears the issues live with the repository. So perhaps you will also lose all issues when mercurial repositories are deleted. Similar story for downloads.
So it appears that you must individually:
Convert your source code repository
Convert your wiki repository
For "Downloads" associated with the repo, you must individually download all files, then re-add them in association with your new git repository
Apologies for being absent with news on my GitHub migration tool, but I had several things happen in my personal life that meant I had limited time to spend developing it. That said, it's now in a sufficient state for people to use. I would still class it as an 'alpha' release (so use at your own risk) but it's worked well for me for a large migration I did. It can be found here along with documentation on how to install/use it.
It doesn't do everything I wanted it to, the main things missing are import of wikis and author mapping for commits. However, both of these steps can be done manually (which I have outlined) so hopefully it is not the end of the world.
Some relevant information:
If you have already migrated to GitHub, you can still use this to publish an archive of issues/pull-requests/etc.
If you are not moving to GitHub, you can still use this to create an archive of issues/pull-requests/etc. You will just have to publish it somewhere (and it won't contain links to diffs or source files)
The issue importer is better than anything else out there. It will link to issue attachments and pull-requests (if you publish the archive on GitHub pages), it will rewrite commit hashes, it will rewrite src file links, it will rewrite links to issues/src files/PRs in other repositories if you migrate them with this tool at the same time (and convert things to the GitHub auto-linking syntax which BitBucket doesn't support).
Here is an example migration I did today. Main repositories (feel free to browse the issues to see how they have been migrated), all forks, and the archive of issues/PRs.
The archive is not very well formatted at the moment, but it's just a single-page application written in AngularJS reading JSON files. All the information from BitBucket is in those JSON files, so the AngularJS app can be expanded in the future to display more info or have nicer formatting. If anyone wants to help out with that (aka is good with AngularJS/HTML/CSS) please check out the issues on my project here.
I hope someone finds it useful. Let me know if you have any questions or run into any difficulties.
We (ECsoftware) left BitBucket and Atlassian, for good. It's a bitter way to depart, but we see no other way. We are now on HelixTeamHub and love it :-) Our 'open' stuff will be on GitHub, in a short while.
What can you do? For myself, I'm removing most of my repositories (and will only keep testing repos created for testing Jira and/or BitBucket). Still can't believe BitBucket didn't come up with an automated migration tool. Such a waste of time for so many devs out there. Thumbs down, BitBucket. Thumbs down so much!
@MartinHvidberg Glad to hear you are loving Helix TeamHub! We're planning to add support for Mercurial wikis in our next release (since right now all wikis are stored in Git repositories within TeamHub). This was based on some of the feedback gathered in this community thread. Thanks for giving our product a try!
@brent_schiestlIt is good to see more tools supporting Mercurial. The community is having a meeting in Europe next month: https://www.mercurial-scm.org/wiki/5.4Sprint we would be happy to have someone from Perforce with us to exchange around your solution.
Here is my Bash scripts kit for Bitbucket Mercurial repositories migration, I hope it will be useful for someone
UPDATE: Now I implemented automatic Bitbucket Mercurial repositories to Git conversion with with HGGIT and this PHP Bitbucket API client library. The script just takes Bitbucket credentials and coverts all user's Mercurial repositories to Git.
There is an official python-hglib, there's also an awesome GitPython and there's also fast-export (recommended by GitHub). If one would simply combine the three (and get lots of lots of kudos), that would be simply awesome.
- Use localy RSA keys (if available, which can be the default case) - Keep the level of privacy (which means, if repository has been private, keep it private).
- Clone repo (into some temporary dir).
- Convert repo to Git.
- Push repo to same account, keeping same name, only appending the given suffix.
Just one command to do all the work. Or even better (the best case), just provide your username and let ALL mercurial repos converted to Git.
There is an official python-hglib, there's also an awesome GitPython and there's also fast-export (recommended by GitHub). If one would simply combine the three (and get lots of lots of kudos), that would be simply awesome.
Expected usage (from terminal):
hg-to-git --username={USERNAME} --repository={REPONAME} --suffix={SUFFIX} So that it would:
- Use localy RSA keys (if available, which can be the default case) - Keep the level of privacy (which means, if repository has been private, keep it private).
- Clone repo (into some temporary dir).
- Convert repo to Git.
- Push repo to same account, keeping same name, only appending the given suffix.
Just one command to do all the work. Or even better (the best case), just provide your username and let ALL mercurial repos converted to Git.
There is an official python-hglib, there's also an awesome GitPython and there's also fast-export (recommended by GitHub). If one would simply combine the three (and get lots of lots of kudos), that would be simply awesome.
Expected usage (from terminal):
hg-to-git --username={USERNAME} --repository={REPONAME} --suffix={SUFFIX} So that it would:
- Use localy RSA keys (if available, which can be the default case) - Keep the level of privacy (which means, if repository has been private, keep it private).
- Clone repo (into some temporary dir).
- Convert repo to Git.
- Push repo to same account, keeping same name, only appending the given suffix.
Just one command to do all the work. Or even better (the best case), just provide your username and let ALL mercurial repos converted to Git.
It doesn't automate cloning them from bitbucket or pushing them on github, but in the coming days @philipstarkey's tool for migrating issues and archiving static HTML of PRs etc may add support for using my tool to do the conversion instead of github's importer, at which point the two tools together will basically cover the whole conversion process.
It is hard to integrate them into a single tool because `hg-fast-export` is Python-2-only at present, whereas @philipstarkey's tool is Python-3. You will need separate Python environments to run them.
Nonetheless this is what I would recommend for the most comprehensive conversion.
The advantage of my tool over `hg-fast-export` is that it (in a temporary copy of the hg repo) amends anonymous heads and bookmarked heads to convert them to named branches so that they survive the transition to git, which is something `hg-fast-export` does not presently support (it just errors if such heads exist).
The advantage of my tool over github's importer is that gtihub also doesn't import anonymous/bookmarked heads, and it also has a bug whereby merge commits have the incorrect ordering of parents, making it look like the default branch was merged into a feature branch instead of the other way around. This leads to incorrect diffs for merge commits, and less-than-useful commit graphs.
There is an excellent migration tool at https://bitbucket.org/edrandall/bitbucket-hg-to-git - it handles metadata and history. It works cross-platform. It doesn't handle wikis nor issues (releases....) - however, there are some other tools that do, so these could be combined.
If you are working on tools, please take a look at the existing ones in this thread.
I'm using this tool to automatically back up all of my bitbucket repositories (so you don't have to clone them all manually). It only preserves source code, not issues/wikis through.
Like people said, it's unacceptable to simply delete the code with a less than a year notice. It's understandable that maintaining two backends and APIs is a pain, but it can be worked around and made static and read only.
It's bad enough public repositories, but some people will also find their private repositories deleted one day. Is archiving and later takeout really not an option?
Since new Mercurial repos can't be created anymore, let us know if you need one. We at Lombiq have created a few of them to spare :). Since repos can still be renamed and transferred we can hand some over to you!
Since a certain company seems to be advertising their services in this thread (wonder if Atlassian minds people doing that), maybe someone should mention Kallithea if it hasn't already been mentioned:
Yes, you have to host it yourself, but that shouldn't be beyond the wit of a lot of software development outfits. There may well be people offering project hosting services based on the software, too.
@hilladalins Atlassian are refusing to give specific answers but it seems that they will be deleting everything.
If you want a record of pull requests, I suggest you check out the tool I made (mentioned by me a few posts ago). As far as I know it's the only one that can save a record of Pull Request discussions. You do not have to move your repositories to GitHub to use my tool to archive your BitBucket data (although it will do that too...but I'm working on improving that step though so I would recommend holding off on moving to GitHub for a couple of weeks if possible if that was your plan)
528 comments