Recapping the London Mercurial Sprint

Introduction

The London sprint, hosted by Jane Street and organized by Pierre‑Yves David, Raphaël Gomès, and Arun Kulshreshtha, gathered just under twenty developers for three intensive days. While the agenda mixed hands‑on coding with high‑level design discussions, the event produced concrete contributions to Mercurial’s core, its ecosystem tools, and several forward‑looking research topics.

---

Day 1 – Bootstrapping and Immediate Wins

The first day was deliberately low‑friction: participants tackled long‑standing tickets and simple maintenance tasks to lower the barrier for occasional contributors.

• Bug fixes – #1965, #1968‑#1971, #1976 addressed regressions in the command line and Windows console handling.
• Documentation – improvements in #1967, #1975 and the community‑run poulpe issue #82 clarified extension authoring.
• Website – hg‑website#31 refreshed the project landing page, making the roadmap more visible.
• New debug command – #1973 introduced hg debugsyntheticrepo, a tool that builds a synthetic repository from an arbitrary DAG, invaluable for testing edge cases.
• Larger work – early progress on #1974 (large‑scale repository handling), #1966 (CI image updates) and ci‑images#66 (Docker‑based CI improvements) set the stage for future releases.

External projects also benefitted:

• hg‑git – Manuel Jacob outlined a plan to address its technical debt, paving the way for smoother Git‑Mercurial interop.
• Heptapod – Georges Racinet managed the 18.10.4 and 18.11.4 releases and discussed moving Heptapod toward a “cloud‑native” architecture (heptapod#1647).
• Windows console encoding – a remote session with Matt Harbison from the US identified a deprecation path for the problematic encoding handling.

Day 2‑3 – Visionary Discussions and Prototypes

The latter two days shifted focus from immediate fixes to architectural explorations that could reshape Mercurial’s scalability and usability.

1. A Virtual File System (VFS) for Mercurial

Large repositories strain the traditional checkout model: a Rust‑based parallel hg update can still spend seconds on kernel writes and inode creation. Inspired by the VFS solutions used at Microsoft and Meta, the sprint team reviewed the experimental read‑only FUSE prototype that already reduces first‑interaction latency from >20 s to <2 s, with only a modest 10‑20 % runtime overhead.

Key next steps discussed:

• Extending the VFS to support hg status and hg update without falling back to the native filesystem.
• Designing a write‑layer that can overlay changes on the virtual view, preserving Mercurial’s transactional guarantees.
• Evaluating performance trade‑offs between a pure‑user‑space implementation and a kernel‑module approach.

2. Heptapod’s Role in the Ecosystem

Georges Racinet gave a concise overview of Heptapod’s current state, clearing misconceptions about its compatibility with GitLab extensions and highlighting a few user‑reported issues that were resolved on the spot. The discussion also identified blockers for upgrading Heptapod to Mercurial 7.2, most notably dependency alignment with the latest GitLab components.

3. Scaling Obsolescence‑Marker Exchange and Bundle Caching

Florian Horn, Laurent Bulteau, and Pierre‑Yves David presented new algorithms for exchanging obsolescence markers (obsmarkers) and for caching bundles. The upstream implementation, still in early stages, promises substantial reductions in network traffic and disk I/O when synchronising large, long‑running histories. A dedicated follow‑up post will detail the mathematical model once the code reaches a usable state.

4. First‑Class Conflict Models

Conflicts are inevitable in any distributed VCS, yet most systems provide only ad‑hoc UI for their resolution. The sprint examined three contrasting approaches:

• Pijul’s patch‑based model – a mathematically rigorous system that treats changes as first‑class objects.
• Jujutsu’s state‑based model – focuses on explicit merge semantics for multiple heads.
• Mercurial’s existing branch‑centric model – robust for safe mutable history but lacking a formal conflict theory.

Participants, including Pijul creator Pierre‑Étienne Meunier and GitButler’s Caleb Owens, debated the feasibility of integrating a formal conflict calculus into Mercurial. While no definitive solution emerged, the dialogue surfaced concrete research questions: how to define a “change” across divergent histories, whether N‑way merges can be expressed without exponential blow‑up, and how history rewriting interacts with patch‑level conflict detection.

5. Normalized and Composable History Sharding

Google’s narrow‑clone extension, upstreamed in 2018, allowed clients to fetch a subset of a repository’s history but suffered from brittleness and heavy server‑side requirements. The sprint introduced store shapes, a server‑side configuration that declaratively describes path‑based inclusion/exclusion patterns across the entire history. Benefits include:

• Reusable clone‑bundle definitions for common workflows.
• Nestable patterns that can be composed to express complex access policies.
• Fingerprint generation for cache validation.
• A foundation for a permissions layer built directly into the storage backend.

Several attendees expressed interest in sponsoring further development, particularly for corporate environments that need fine‑grained repository slicing.

6. Evolution: Safe Mutable Distributed History

Mercurial’s Changeset Evolution feature enables draft history editing without sacrificing safety. Caleb Owens contrasted this with GitButler’s approach, which adds explicit synchronization barriers to a CRDT‑based content model. The discussion highlighted two complementary insights:

• Mercurial’s richer data model can represent a broader set of editing operations without requiring centralized coordination.
• GitButler’s UX work—especially around “eager rebasing” pitfalls—offers valuable lessons for improving Mercurial’s own UI for history rewriting.

A side outcome was the decision to prototype a marge‑bot for Heptapod, mirroring GitLab’s merge‑request automation; the code will be open‑sourced soon.

7. Git Compatibility – Embrace, Extend, or Extinguish?

Given Git’s dominance, the sprint revisited the long‑standing question of bi‑directional interoperability. Raphaël Gomès and Caleb Owens explored a pragmatic path: rather than fully implementing the Git wire protocol, Mercurial could expose a read‑only Git façade for IDEs, AI assistants, and other tooling that expect a Git repository. Coupled with the VFS layer, this could deliver near‑native clone performance while keeping Mercurial’s internal model intact.

8. The Hyperlog – A Next‑Generation Storage Format

The revlog has served Mercurial for two decades, but its monolithic design limits further scaling. The sprint team outlined the Hyperlog (revlog V2), featuring:

• Mutable index entries for on‑the‑fly updates.
• Separate index and data files to improve memory locality.
• Sparse files with default values to reduce disk footprint.
• Unified file‑log structures that dramatically cut the number of files on disk.

If adopted, Hyperlog would enable truly first‑class changeset evolution, faster narrowing/widening of histories, and more efficient bundle discovery—all without relying on external caches.

---

Meta‑Recap

The London sprint succeeded on multiple fronts: tangible code contributions, clarified roadmaps for Heptapod and hg‑git, and a wealth of strategic ideas ranging from VFS integration to a new storage engine. The collaborative atmosphere persisted well beyond office hours, even if the group forgot to snap a group photo. The only visual record is the whiteboard sketches captured below.

Thank you to everyone who contributed time, expertise, or moral support. We look forward to the next sprint, whose planning has already begun, and to the continued evolution of Mercurial as a free, open‑source version‑control system.

Mercurial 7.2.2 has been released alongside these efforts.