The Trosnoth source code has been kept in a Mercurial repository on BitBucket since not long after we migrated from Subversion many years ago. But BitBucket no longer supports Mercurial repositories: all existing Mercurial repositories on BitBucket will be shut down on 1 June.
So the Trosnoth source repository will soon be migrating to Heptapod. Heptapod is a ‘friendly fork’ of GitLab community edition, built with the purpose of bringing Mercurial support to GitLab. In January, Octobus and Clever Cloud announced that they were offering free Heptapod hosting to open source projects (within certain parameters). They have also said that they plan to offer commercial hosting for non-open-source projects soon.
Why not self-host the mercurial repository?
If all we wanted was somewhere to host the Trosnoth source code, we could easily have set up hosting on our own server, and linked it to a trac instance. In fact, that’s what we originally did before moving to BitBucket. The motivation for moving to BitBucket in the first place was to make public collaboration easier. Platforms like GitLab, GitHub, and BitBucket make the Trosnoth project easy to discover, and provide straightforward tools for contributing to it. In contrast, self-hosting the repository only provides the bare essentials for collaboration.
(These platforms also provide added bonuses like easy automated builds and tests—Trosnoth used BitBucket Pipelines to run our test suite. But collaboration is the main draw-card for us.)
Why not migrate to Git?
When BitBucket announced they were shutting down Mercurial repositories, we seriously considered migrating the Trosnoth repository to Git. After all, Git has become the far more popular choice for distributed version control. This option could still be on the table if things change in the future, but for now, we’ve chosen to stick with Mercurial. Here are a few of our reasons:
It’s less effort. The easiest option is not always the best option. But in an open source project which nobody’s paid to work on, effort spent migrating to Git is effort that isn’t being spent improving and developing Trosnoth itself.
Mercurial is easy for newcomers. If you’re a software developer these days, the odds are that you’ll have to learn Git at some stage. But when we use Trosnoth as an example project for high school students, none of them have ever used version control software before, and some of them may never use it again. I want to give them a positive experience of version control, and Mercurial is very friendly to newcomers. (From what I’ve seen, Mercurial is sometimes confusing for those who’ve come from Git, but that’s mostly because ‘branch’ and ‘pull’ don’t mean what you expect them to mean.)
Converting from Mercurial to Git is lossy. You don’t lose a lot in the conversion. And it’s true, you can generally live without what you’ve lost. And people who really buy into Git’s philosophy tell me that most of what you lose in the conversion (e.g., branch name metadata on every changeset) is clutter that you don’t want to keep anyway. But I disagree. The main difference I’ve seen between Mercurial and Git is that Mercurial aims to record project history, while Git aims to record patches. This might seem like the same thing, but imagine this: you’ve spent months working on a rewrite to a major part of your project and in the end you decide to scrap your work. Maybe the original need is no longer as pressing, or perhaps you realise that your rewrite doesn’t add as much as you’d first hoped. So you get rid of your branch and move back to the main line. If you’re using Mercurial, the history of your ill-fated rewrite is still preserved, and you can go back and view it any time you like. If you’re using Git, all your changes are lost unless you take a deliberate action to preserve them (e.g., create a tag). I prefer Mercurial’s default behaviour, because I never know when I might want to reuse something I did in an old branch. Differences like this cause challenges when converting from Mercurial to Git: I have to make a conscious decision what to do with each closed branch during the conversion, and if I have closed heads within a branch things get even worse. And this brings us back to the first reason to stick with Mercurial: it’s less effort.
Sticking with Mercurial is good for the internet. I admit that this reason is a philosophical one, and wouldn’t hold much weight if all the practical pressures said we needed to convert to Git. But the truth is, it’s better for everyone when there are multiple choices available. Chrome gets better because it has to compete with Safari, Firefox and Edge. And over their histories, Git and Mercurial have both borrowed features from one another. If Mercurial dies out, Git will be the worse for it. So we have very few misgivings about sticking with the underdog here. Mercurial may not be the popular choice, but it has very few other disadvantages, and we commend Octobus for starting the Heptapod project and helping keep Mercurial alive.