Frame the decision

"Which VCS should we use?" rarely has one right answer. The correct frame is: "What constraints does our work impose, and which system best fits?" The constraints fall into a few categories.

The honest case for Perforce

This article is a counterweight. Most modern engineering blogs assume Git is the answer. For a meaningful set of projects, Perforce is genuinely the better choice. Knowing when is a real engineering decision.

The cost question

Perforce / Helix Core is commercial software. Pricing varies by plan but typically lands around USD 25-50 per user per month for cloud hosting, more for self-hosted enterprise tiers with full features. Git itself is free; hosting on GitHub or GitLab ranges from free (for limited tiers) to USD 20-30 per user per month for enterprise plans.

Cost alone does not decide it - the question is what each price gets you.

Why locking matters

Some files cannot be merged. A 3D model in .fbx, a Photoshop file in .psd, a CAD assembly - all are binary, and concurrent edits cannot be reconciled. Without an exclusive lock, two artists can spend hours editing the same file in parallel, only to discover one's work is unreachable.

Perforce's locking model

Perforce treats files as having an explicit checkout state. Marking a file as +l in its filetype enables exclusive locking - only one user at a time can hold a writable copy. Workflows assume this:

Different problems, different solutions

Perforce was released in 1995 - a decade before Git or Mercurial. It targets a particular shape of problem: large, often binary content; highly regulated workflows; teams that need fine-grained access control and exclusive locks; projects measured in terabytes, not gigabytes. Game studios, film VFX houses, hardware design firms, and aerospace companies are typical users.

The 2005 inflection

BitKeeper had been the Linux kernel's VCS until April 2005, when licence disputes ended that arrangement. Linus Torvalds wrote Git in 10 days. Matt Mackall began Mercurial weeks later, with similar goals and similar performance. The two systems competed for adoption from a level start.

Performance vocabulary

"Performance at scale" can mean many things: clone time, log/blame speed, commit throughput, working tree size handling, network bandwidth efficiency, or scaling to thousands of concurrent contributors. Git and Mercurial have evolved on different fronts.

Clone and fetch

Git's pack files use aggressive delta compression; clones are typically efficient. Mercurial uses bundle files with similar compression. For repositories under 1 GB, both clone in a minute or two over a typical connection.

Two ecosystem shapes

Git's ecosystem is sprawling, market-driven, and uneven. Mercurial's is smaller, deliberate, and more cohesive. The trade-off is comprehensive availability versus focused quality.

Hosting

Git hosting is everywhere: GitHub (~100M users), GitLab, Bitbucket, Gitea, Forgejo, sourcehut, self-hosted options at every price point. Mercurial hosting has thinned dramatically: Bitbucket dropped Mercurial in 2020; SourceForge supports it; Heptapod offers Mercurial hosting on a GitLab fork. New Mercurial projects find hosting choices limited.

Two design lineages

Git's CLI emerged organically. Linus Torvalds and the early team valued power and speed; commands accumulated over years, often by different contributors with different sensibilities. Mercurial's CLI was designed top-down by Matt Mackall with a deliberate focus on consistency and discoverability.

Same era, different aesthetic

Git and Mercurial were both released in April 2005, both as responses to BitKeeper's licensing fallout. Linus Torvalds wrote Git for the Linux kernel; Matt Mackall wrote Mercurial as a competing alternative. Both are content-addressed, distributed, DAG-history systems - and both work.