A DVCS written in Python
Mercurial 1.0 was released on 19 March 2008 by Matt Mackall. The project had started in April 2005 — the same week as Git’s first commit — as the community’s answer to BitKeeper’s abandonment for Linux kernel development. While Linus Torvalds took the path of a ground-up C rewrite, Matt Mackall chose Python as main language (with performance-critical modules in C), prioritising readability and extensibility over raw speed.
Version 1.0 formalises three years of stabilisation: data architecture, user commands, network protocol. It is distributed under GPLv2 (later GPLv2+ with 2.x).
Data architecture
Like Git, Mercurial is a DVCS — each clone contains the full repository history. Unlike Git, Mercurial’s data model is more conventional:
- History as a DAG of changesets, each identified by a SHA-1 hash
- Revlog as storage format — one append-only file per tracked file + one for the manifest, with incremental deltas
- Manifest per changeset — filesystem snapshot at that moment
- Named branches as changeset attribute (not movable pointers like Git)
- Explicit rename and copy tracking, not inferred by similarity
The result is a system in which common operations are predictable and documentable. A CVS or Subversion user finds in Mercurial a mental model more accessible than Git’s, with equal distributed power.
Commands and usability
The main commands — hg clone, hg pull, hg push, hg commit, hg update, hg log, hg diff, hg status, hg merge, hg branch, hg tag — have orthogonal and consistent names and semantics. Each command does one thing, without modes (unlike Git, where many commands have flags that radically change behaviour).
Extensions (official subsystem, plus third parties) let Mercurial be extended with optional features — mq (Mercurial Queues for patch management), rebase, churn, color, progress, transplant, hgk.
The integrated web interface hgweb provides a repository browser without external dependencies.
Network protocols
Mercurial supports transport via:
- HTTP(S) — through
hg serveorhgwebon Apache/Nginx - SSH
- Local filesystem (bundle files)
The protocol is efficient in sending incremental changesets: initial clones are comparable to Git, subsequent pulls are optimised.
Institutional adoption
As of 2008 Mercurial has gathered significant adoptions:
- Mozilla migrates Firefox and Thunderbird from CVS to Mercurial in 2007-2008
- OpenJDK (Sun Microsystems / then Oracle) — migration from 2007
- Python itself — the language adopts Mercurial in 2009 for the CPython repository, replacing Subversion
- Xen hypervisor
- Xen Project repository
- NetBeans (Sun)
- Many OCaml, Haskell, scientific projects
The choice is often motivated by a lower learning curve vs. Git, the fact that everyone can read the code (Python) and contribute to core, and the API stability of extensions.
Bitbucket
In 2008 Bitbucket is launched as hosting dedicated to Mercurial — the functional equivalent of GitHub for the Hg world. Atlassian’s acquisition in 2010 consolidates the service, which will add Git support years later.
GitHub/Bitbucket competition partially mirrors Git/Mercurial competition, with GitHub progressively prevailing.
Graphical tools
The Mercurial ecosystem in 2008-2009 includes:
- TortoiseHg — Windows Explorer integration (analogue to TortoiseSVN for SVN)
- hggit — extension for Git repository interoperability
- Kiln (Fog Creek) — enterprise Mercurial hosting
- MacHg, SourceTree — graphical clients
Comparison with Git
Over ten years past release, the community verdict is that Git has prevailed in overall adoption, but Mercurial has retained a consolidated user base in environments where its strengths are appreciated:
- Simpler data model — lower learning curve
- Python extensibility — custom enterprise plugins simpler
- Comparable performance on medium-sized repositories; Git wins on very large repositories thanks to aggressive C optimisations
- Immutable history by default — Mercurial makes it harder to rewrite already-pushed changeset history (except via mq or hg strip), appreciated where audit trail is critical
Facebook/Meta is a particular case: it has heavily invested in Mercurial (developing Sapling as Mercurial-compatible evolution in the early 2020s) to manage its exceptional-scale monorepo.
In the Italian context
As of 2008 Italian Mercurial adoption is modest, with usage clusters:
- University Python research groups — Mercurial being Python and CPython using it as reference repo naturally drives adoption
- Some software houses specialised in Java/Python preferring Hg’s usability to Git’s
- International projects (Mozilla, OpenJDK, Xen) with Italian contribution
Git will establish itself as the dominant Italian choice in 2010-2012 with GitHub’s pull effect; Mercurial will retain use in existing projects.
Historical role
Mercurial 1.0 shows that a quality DVCS can be built with a high-level interpreted language without substantial performance compromises for the vast majority of use cases. This technical demonstration — that “Python is fast enough” for a demanding application like version control — influences beyond the specific project: it contributes to consolidating Python as language suited to serious development tooling, not just scripting or scientific research.
References: Mercurial 1.0 (19 March 2008). Matt Mackall. GPLv2 licence. Mozilla, OpenJDK, Python CPython, Xen as early adopters. Bitbucket (2008, later Atlassian 2010). TortoiseHg.