Heptapod 0.18.0rc2 released, with Rust in Mercurial
We're very glad to announce the release of Heptapod 0.18.0rc, featuring GitLab 13.5 and Mercurial 5.6.1 built with Rust. Thanks to all those that helped during this development cycle.
It is specially heartening to see Heptapod and the Rust reimplementation of some parts of Mercurial, two major development efforts led by Octobus, be finally joined together. The Rust parts have to be explicitely activated, see below for more details.
The release candidate was installed on December 14th on foss.heptapod.net and is running the Rust code at the moment of this writing.
Heptapod 0.18.0rc2 can be installed as a Docker image and from source.
The full changelog is available as usual alongside the sources.
Short term schedule for release and installations
The RC phase will end on December 21st, with the final release of Heptapod 0.18.0 and immediate installation on the flagship platforms: foss.heptapod.net and heptapod.host.
Meanwhile, heptapod.host will get its last 0.17 update on December 16th with the installation of the 0.17.3 to be soon released.
GitLab 13.4 and thus Heptapod 0.17 will reach end of life on December 22nd.
Rust-enhanced Mercurial in Heptapod
Since the end of 2018, alternative implementations of Mercurial internals in the Rust programming language have been under development, with drastic performance improvements being the obvious goal.
Starting with version 0.18.0rc2, Mercurial enhanced with Rust is an option in Heptapod that has to be explicitely activated.
Activating Rust parts of Mercurial in binary distributions
Binary distributions Omnibus packages and Docker images will ship Mercurial compiled with Rust, but the Rust parts are left disabled by default. To activate Rust, add this to /etc/gitlab/gitlab.rb or the `` environment variable of a Docker container:
mercurial['invocation']['module_policy'] = "rust+c"
This requires a container restart or a call to gitlab-ctl reconfigure.
For the record, the default "policy" is "c", but the simplest way to get back to the default behaviour is to comment out this policy setting.
Activating Rust parts of Mercurial in source installations
There is a Rust variant of the install procedure. It boils down to using a different Python requirements file.
Once that is done, the Rust parts of Mercurial are enabled by default and can be disabled at any time, by changing the "module policy" in four different configuration files.
Expected performance improvements
This is a first step in which we don't expect performance improvements to be very visible yet, but please try it early and report back. This will certainly help us moving forward to reap the expected benefits down the road.
Right now, we can expect some algorithms about the graph of changesets to become faster, but they don't amount for a significant portion of the time spent, and are often running in background jobs anyway.
Basically, we're doing this now so that we will be ready when it will start to matter, for example in the handling of large repositories once other bottlenecks are removed. The conversion to Git that we are also actively working on removing is a prime example of such bottlenecks.
The most significative performance improvement will come with the activation of the persistent nodemap with Rust implementation. We'll probably include this in the next Heptapod release. This persistent nodemap eliminates a source of server-side latency in push/pull operations for large repositories (for all Mercurial servers) and also in the rendering of cross-references to changesets (specifically for native Mercurial repositories in Heptapod). This illustrates in particular how diverse the impacts of such low-level improvements can be. We can expect the change to be felt with repositories around 100 000 changesets, such as PyPy and Heptapod (Rails).
Of course Rust is an active development area in Mercurial, meaning that future versions can provide us with more visible improvements that we'll be glad to leverage immediately.