Heptapod as a BitBucket replacement
Many times over the past few months, we've been asked if Heptapod was to be the perfect haven for teams in search of a new DVCS home after they must flee from Bitbucket?
We're hereby inviting all generic projects related to Mercurial on our main Heptapod instance. Read below for more details about that, the current state of our Bitbucket import feature, and future hosting plans.
It's always been part of the plan
To recall, on August, 20th of this year, BitBucket announced that they will be dropping support for Mercurial in the first semester of 2020, culminating by the removal of all Mercurial repositories on June 1st, 2020.
When Octobus launched the Heptapod project, we had two goals. The first was to showcase a clear and focused way to use modern features of Mercurial, and especially its history rewriting capabilities. Some of that is detailed in our workflow blog post.
The other goal was precisely to provide an alternative people could turn themselves to, should Bitbucket drop Mercurial support. While we had reasons to fear that this could happen, we didn't expect it to happen so fast. What we didn't foresee either was the rise of sourcehut, which looks indeed like the perfect solution for email based workflows.
Since Bitbucket's announcement, we've been working hard to bring Heptapod up to speed to serve as a possible replacement, putting a stronger focus on import features.
Importing projects from Bitbucket into Heptapod
Importing from Bitbucket is a standard GitLab feature, of course restricted to Git repositories in upstream GitLab. Although we had to deactivate it in the early Heptapod prototype, it's been rather straightforward to bring it back.
The Bitbucket import works in Heptapod as in upstream GitLab, except of course that it's currently for Mercurial repositories only. If you want to use it on your own instance, just follow the standard instructions.
During the Heptapod 0.6 timeframe, we did many experiments involving the Bitbucket import. Notably, we made several test runs for the PyPy project, an interesting case with its 95000 changesets, lots of issues and a worklow with named branches based on the issue number. Of course, that import takes quite some time, but it works.
There is a specific category of Heptapod issues about the Bitbucket import. We currently lack an important one (Pull Requests from forks), but we are confident it'll be available in a couple of weeks.
Inviting Mercurial projects on dev.heptapod.net
We decided long ago that the main instance for development of Heptapod itself could also host projects directly related to Mercurial. It started because we thought some pieces needed for Heptapod would be more generic anyway, but it quicly outgrown that.
So, dev.heptapod.net has long had a group of Mercurial generic
projects. We've imported some extensions
that we care about ourselves since then, such as config-express,
format-source and most recently, hg-git. These benefit right now from our
powerful Continuous Integration (CI).
As a service and contribution to the Mercurial community, we're now inviting all open-source projects related to Mercurial that are hosted on Bitbucket to come over to dev.heptapod.net.
For that to happen, you'll have to file an issue in the tracker for
dev.heptapod.net,
with the Hosting Request label. All discussions about it shall be public.
Here are the requirements the repository to import has to fulfill:
- related to Mercurial: that includes extensions of course, but also external tooling, such as graphical interfaces, server utilities.
- currently hosted on Bitbucket: we want to focus on projects that are in need of new home soon.
- fully Free/Libre Open Source projects only. By the way, everything on dev.heptapod.net is public.
- be the main development repository, the reason being that we don't want to host hundreds of secondary clones there, whose relevance wouldn't be clear.
- have official releases. More generally, we'll give priority to mature projects with a significant user base, or that we are using ourselves.
This list is by no means complete. Some of these requirements might be tightened up or loosened in the future. Basically, we'll see how it goes and adjust accordingly.
If in doubt, just file an issue anyway. Be assured that we'll be gentle if we have to tell you that your project does not belong there.
Plans for general hosting
Public hosting is a resource-intensive endeavor that requires lots of work force or process automation, especially with the delicate subject of moderation.
Heptapod is still currently developped and hosted primarily by Octobus. Being a small consulting company, Octobus doesn't have extensive hosting capabilities by itself, hence can't do this alone.
What Octobus can do however is to explore partnership opportunities with existing hosting companies in order to build a commercial offer and explore possibilities for shared public hosting.
This is what we are doing now. It's too early to be really specific. Just stay tuned.