By admin , 29 April 2026

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.

Workload constraints

  • Mostly text code, frequent branching → Git.
  • Mostly binary content, exclusive locks essential → Perforce.
  • Mixed, with cleanly separable code and assets → run both.
  • Centralised control with simple branching → SVN remains acceptable.

Team constraints

  • Distributed, often offline → distributed VCS (Git, Mercurial).
  • Single-site, always online → either model works.
  • Mixed engineers and non-engineers (artists, writers) → friendlier UX matters; Perforce or Mercurial.
  • Open-source contributors → Git, no question.

Ecosystem constraints

  • CI/CD modernity → Git overwhelmingly.
  • Game engine / DCC tooling → Perforce often, with Git for code.
  • Existing infrastructure → continuity has real value; switching has real cost.

Compliance constraints

  • Per-path access control → Perforce or SVN.
  • Server-side audit of read operations → centralised systems (Perforce, SVN).
  • Signed commits and supply chain attestation → Git with sigstore-class tooling.

Cost constraints

  • Bootstrap with no budget → Git on GitHub free tier, GitLab CE, or Gitea.
  • Funded enterprise with binary needs → Perforce justifies itself.
  • Mid-size SaaS team → GitHub or GitLab paid tier.

Decision tree

1. Is most of your content unmergeable binary?
   Yes → Perforce (or Perforce + Git hybrid). Stop.
   No → continue.

2. Do you need per-path access control or read auditing?
   Yes → SVN, Perforce, or Git with significant tooling investment.
   No → continue.

3. Do contributors work offline or distributed?
   Yes → Git (or Mercurial). Continue.
   No → either model is fine.

4. Do you need GitHub-style ecosystem?
   Yes → Git. Stop.
   No → consider Mercurial for UX, SVN for centralisation.

5. Default → Git.

Sample scenarios

  • Web SaaS startup, 5 engineers → Git on GitHub or GitLab. Use GitHub Flow.
  • Game studio, 200 people, half artists → Perforce for assets, Git for code.
  • Government agency, regulated, 50 engineers → Self-hosted GitLab with branch protection and signed commits, or Perforce if binary content dominates.
  • Open-source library → Git on GitHub. PR-based contributions.
  • Internal corporate tooling, 20 engineers, no offline needs → Git is still the answer in 2026 - the ecosystem benefit dominates.
  • Hardware design firm with CAD-heavy work → Perforce; possibly Git for embedded firmware.

Migration paths

# SVN to Git
git svn clone --stdlayout --authors-file=authors.txt <url>

# Mercurial to Git
~/fast-export/hg-fast-export.sh -r <hg-repo>

# Perforce to Git
git p4 clone //depot/main@all my-git-repo

Tooling exists for every direction. The mechanical conversion is rarely the hard part - culture, tooling, and habit are.

Avoiding analysis paralysis

If you cannot decide, the answer is Git. It is the largest ecosystem, the most familiar tool to new hires, and the easiest to migrate from later if needed. Reach for SVN, Mercurial, or Perforce only when a specific constraint demands them.

Reviewing the choice

Re-evaluate every two years. New engines, new compliance regimes, new tooling can change the calculus. The decision is not forever; the work to reverse it is real but tractable. Pick deliberately; revisit calmly.