Version control is one of the few decisions a project makes that outlives the framework, the cloud provider, and most of the people who chose them. In 2025 the shortlist is still three names: Git, Mercurial, and Subversion. Git takes nearly every new project by default, but "default" and "right" are not the same word. If you are maintaining a fifteen-year-old Subversion repository, or your team keeps tangling itself in Git merges, it is worth twenty minutes to compare all three honestly.

What Each System Really Is

The architectural difference between these tools explains almost every practical difference you will feel day to day.

• Git — distributed, created in 2005 for Linux kernel development. Every clone carries the full history, commits are local until you push, and history is a chain of immutable snapshots addressed by hash.
• Mercurial — also distributed and also from 2005. It stores revisions as snapshots in a revlog, ships as a Python command-line tool, and was designed from the start to be approachable.
• Subversion — centralized, released in 2000 as a CVS replacement. One server holds the history, working copies are checkouts, and revisions are plain integers that increment across the entire repository.

That last detail matters more than it sounds. In Subversion, revision 4,182 refers to the state of the whole repository. In Git and Mercurial, every clone has its own identifiers, which is why distributed teams can commit on a plane and reconcile later.

Branching and the Shape of Your Workflow

Git and Mercurial treat branches as cheap pointers, so a feature branch costs almost nothing and you can create a dozen without guilt. The two differ in philosophy. Git encourages rewriting: rebase, amend, squash, force-push to a personal branch. Mercurial leans toward an append-only record by default, with named branches that persist, bookmarks that behave more like Git branches, and the evolve extension for people who do want to reshape history.

Subversion branches are directory copies — /branches/feature-x looks exactly like a folder because it is one. Modern Subversion tracks merges reasonably well, but reverting a bad merge or untangling a long-lived branch is more manual work than the same operation in Git. If your team merges twice a year from a release branch, this is fine. If you merge daily, you will feel the friction.

Performance and Repository Size

On text-heavy repositories, Git and Mercurial are both quick; the difference in cloning or logging a typical application repo is measured in seconds, not minutes. Where Git has pulled ahead is enormous monorepos. Shallow clones, partial clones with blob filters, sparse-checkout, and Git LFS are mature escape hatches for repositories that would otherwise be unmanageable. Mercurial has equivalents and some strong large-file handling, but the tooling around them is thinner.

Subversion's weakness is rarely raw speed on a small repo. It is everything that touches history: repeated branch merges, svn log on a large repository, and any work at all when the server is unreachable. Its quiet advantage is partial checkout. Running svn checkout against a single subdirectory is a first-class operation, which is genuinely useful when a repository mixes source code with art, CAD files, or build artifacts. Git can approximate this with sparse-checkout, but only after the clone has already transferred objects.

Learning Curve and Command Design

Subversion wins the first hour. The mental model — one server, one trunk, branches are folders — is easy to explain to a new hire or a designer. Git's staging area is the classic stumbling block; people understand commit long before they understand why add comes first.

Mercurial's command-line interface is the most consistent of the three. Flags behave similarly across commands, the built-in help is genuinely readable, and error messages tend to suggest the fix. If your team writes scripts against the VCS, that consistency pays off.

Whatever you choose, write down the six commands your team uses every day — status, diff, commit, pull, push, and how to undo a mistake — and put them in your contributing guide. Half of all version control complaints are really documentation complaints.

Hosting, Integrations, and Community Support

This is where the gap is widest, and it is not really about the software.

• Git dominates hosting and integrations: GitHub, GitLab, Forgejo, and every CI service worth using assume it. Code review, issue linking, release automation, and package registries all come free.
• Mercurial lost its biggest public host when Bitbucket dropped support in 2020. Remaining options include Heptapod, Sourcehut, and self-hosted hgweb. They work well, but integrations are fewer and the hiring pool for Mercurial-specific experience is smaller.
• Subversion has no major public host. It lives behind Apache or a packaged commercial server, with excellent GUI clients such as TortoiseSVN on Windows. CI plugins exist; they often feel bolted on.

A blunt rule: if you need to onboard contributors or hire, Git wins by default. If you need a tool that slots into an existing release process with no renegotiation, the others can still be the better fit.

When Each One Is the Right Call

Choose Git when

You are starting something new, expect outside contributors, want hosted review and CI without building it, or run a monorepo that needs partial clones. It is also the only realistic option if you plan to hire engineers who already know the workflow.

Choose Mercurial when

You want distributed version control with a gentler interface and a policy against history rewriting. Windows-heavy teams that prefer TortoiseHg, and small stable groups that value readable commands over ecosystem size, get along well with it.

Choose Subversion when

Your repository is enormous, binary-heavy, and only a slice of it is relevant to each person. This is common in game studios, embedded work, and long-lived enterprise projects where a single server of record is an organizational requirement rather than a technical one.

Making the Decision Without Regret

Work through this list before you commit to anything:

1. List the constraints, not the preferences. Air-gapped build servers, binary assets, contributor count, review tooling, and who owns the server. These usually decide the question on their own.
2. Test with the real repository. Clone or check out your largest branch and time it. Do a merge. Look at the log. A prototype on your actual data beats any comparison chart.
3. Check your CI and hosting first. Migrating a repository is a weekend. Rebuilding a pipeline around a newly unsupported version control system is a quarter.
4. Document the workflow. Branching strategy, who merges, how releases are tagged, and how to undo. This matters far more than which of the three you picked.
5. If you migrate, keep the old repository read-only. Preserve it, mirror it if you need history in the new tool, and freeze write access on day one so nobody splits the truth across two systems.

Git is the safe answer for most projects in 2025, and safe is a real virtue. But if your repository is heavy with binary assets, or your team keeps losing time to history rewriting they never wanted, the alternative is not nostalgia. Pick the tool that matches the work in front of you, then stop thinking about it and go ship something.

Photo: cottonbro studio / Pexels