Cross-Cutting Tools Deep Dive · 6 of 6

Mercurial & SVN — The Systems Git Eclipsed

For most of the 2000s, the version-control conversation was three-way: Subversion (centralized, the heir to CVS), Mercurial (distributed, Python, friendly), and Git (distributed, fast, kernel-shaped). Git won. But Mercurial powers Meta's monorepo and a handful of long-lived projects, and SVN still ships in enterprises that never migrated. You'll meet them.

SubversionMercurialCentralizedDistributed
← Back to Cross-Cutting Tools
Subversion (SVN)

Centralized, Lock-Friendly, Still Alive

  • Centralized model. One server holds the canonical history. Working copies are sparse — a checkout pulls only the revisions you need. No .git-style full history per machine.
  • Linear, monotonically-increasing revision numbers. r1234 means the same thing to everyone. Some teams genuinely miss this when they move to Git's hashes.
  • File locking. Useful for binary assets — only one person edits the Photoshop file at a time. Git has no equivalent.
  • Branching is cheap on the server, expensive in practice. Branches are server-side copies; merging back across them is the part that drove people to Git.
  • Where you'll find it: game studios with huge binary asset trees, older enterprise codebases, embedded shops. Apache still maintains it.
Mercurial (Hg)

Distributed, Different Personality

  • Same era as Git. Both 2005, both distributed, both content-addressed. Mercurial chose a more conservative, "safer" UX — fewer footguns, less history rewriting by default.
  • Python codebase with a clean extension model. Branches are slightly different — named branches and bookmarks behave unlike Git branches.
  • Big-tech holdout. Meta extends Mercurial heavily for its monorepo (their Sapling client is open source). Mozilla used it for Firefox until migrating to Git in 2023.
  • Bitbucket dropped Hg support in 2020, which removed the main public host and pushed remaining projects to self-hosting or to Git.
  • Where you'll find it: Meta-adjacent codebases, scientific computing, a few long-lived OSS projects.
Migration Reality

If You Inherit One of These

  • SVN → Git: git svn can clone history. For long-lived repos, svn2git or reposurgeon handle authors, tags, and branch layout better.
  • Hg → Git: hg-fast-export or git-remote-hg. Mostly mechanical — the bigger lift is retraining the team.
  • Don't migrate just to migrate. If the team is happy and the host is supported, the cost-benefit of migration is real but not urgent.
  • Do migrate when the host is being deprecated, when CI ecosystems no longer support your VCS, or when hiring becomes hard.
Continue

Other Cross-Cutting Tools

← Git ← GitHub ← GitLab ← Bitbucket ← Azure DevOps ↑ Back to Cross-Cutting Tools