Bitbucket is sunsetting mercurial

Google Groups archive
1

Hi All,

I just saw this news today and realized that it will impact Orthanc development next year.

https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket

Chris

2

I too noticed this. It was especially untimely with the Mercurial link that Sebastien just posted for the documentation / swagger / OpenAPI.

3

Hello,

Yes, this sad decision will indeed deeply impact the Orthanc project. This is the second time a migration is needed, after the closing of Google Code in 2016.

Several users have pointed out over the last years what they perceived as a lack of consistency: Why does Orthanc use a proprietary platform (such as Altassian’s BitBucket or Google Code), while promoting free software? “Have you ever noticed that you are in a lock-in situation?” I obviously knew this, and I was indeed uncomfortable with it. The reason for this choice is clearly a lack of resources (as in many free software projects), as maintaining a self-hosted infrastructure demands money and maintenance. I have always chosen to be pragmatic by favoring the development of the source code over the administration of a server, to the benefit of the community of medical imaging, while keeping in mind that migration was always possible.

Things are now different, as Atlassian forces us to make much manual work. No automated, transparent migration is planned from Mercurial to git, and the full integrated history of many projects including Orthanc will simply be lost (by the way, Software Heritage shows all of its importance right now). As a consequence, we’ll anyway have to update all the scripts and procedures that revolve around Orthanc.

So, this unilateral choice by Atlassian should be seen as an opportunity to get rid of this dependency. I insist on the fact that the debate here is not “Mercurial vs. git”: The debate is over the dependency of a free software project over a proprietary third-party infrastructure. The following possibilities will now be evaluated by the core developers of the Orthanc project:

  1. Stay on BitBucket, by doing the Mercurial-to-git conversion. This has the advantage of preserving the history of the issue tracker (manual import/export is available).
  2. Move to GitHub, as it is more popular than BitBucket. The history of the issue tracker would be lost, but could be exported to a set of standalone self-hosted static HTML pages.
  3. Move the project to a software forge that is maintained by an academic partner (I’m thinking about GitLab at University of Liège), and consider this as a first step to the migration to a fully self-hosted infrastructure in the future. This has the advantage of reducing maintenance costs in a first time, while being less dependent on a commercial partner such as Atlassian.
  4. Create a self-hosted VM that separately runs Mercurial and an issue tracker (e.g. combining hgwebdir, mercurial-server, and roundup), which would allow them to evolve separately. This has the advantage of being a lightweight solution that would preserve our existing procedures using Mercurial.
  5. Create a self-hosted VM that separately runs git and an issue tracker, and do the Mercurial-to-git conversion.
  6. Create a self-hosted VM that runs a full instance of GitLab (to the best of my knowledge, no such integrated tool exists for Mercurial).

No decision is taken at the present time, although my personal feeling is that self-hosting is probably required now. Fortunately, we still have some months to make the best choice for Orthanc.

So, please continue contributing to the documentation using BitBucket in the meantime :wink:

Kind Regards,
Sébastien-

4

(Sorry if this is a duplicate, I tried to reply yesterday but don’t see it now.)

Just want to revive this thread a bit because they will remove the repository in June.

We have a fork maintained in git that we synchronize using the git-remote-hg plugin and we used hg-git compatibility mode by happenstance. The Atlassian blog post mentions another tool hg-fast-export but I have no experience with it. We’ve found the choice of tool is important because hg-git (and git-remote-hg in compatibility mode) modify some commits, e.g. the second-to-first one looks like this:

commit 61dd9d8a9821d9975f59fdf6841f1a58b88da561

Author: Sebastien Jodogne s.jodogne@gmail.com

Palantir-0.1.0

–HG–

branch : Palantir-0.1.0

I don’t love this result but once you have it is hard to change because there is a cascading effect on the hashes, so if you decide to migrate to git you should be very explicit about which tool you use for the conversion because it will have a big impact on ability to cleanly merge for any existing forks. Concretely, if we used git-remote-hg without compatibility mode, then the “–HG–” part of that commit message would not be there and every single SHA commit hash after that would change. At this point git sees them as totally different despite the actual contents of the commits being otherwise the same and thinks almost every file is a merge conflict.

If you decide to switch to git (which I think is reasonable given its dominant market share and the Bitbucket situation), it may be worth polling the community for existing git users about which tool they used to port the commits.

-Jake Cobb

5

Dear Jake,

After investigating a lot of possibilities, my decision will most probably be the following:

  • As announced in my message of August 2019, we’ll switch to a self-hosted infrastructure.
  • As announced at OrthancCon 2019, Mercurial will still be used (no switch to git, so no export problem like the one you mentioned).
  • Kallithea will be the source code management system (https://kallithea-scm.org/).
  • Roundup should be the bug tracker (http://roundup-tracker.org/), but I’m still investigating alternatives.
    Regards,

Sébastien-