License & Deployment Mix: 10 tools – 7 OSS, 3 proprietary (Perforce Helix Core, Unity Version Control, and the original SCCS); Perforce and Unity VC also ship a vendor-hosted edition. Two entries (SCCS, CVS) are historic, included for lineage context.
What Is a Version Control System?
A version control system (VCS) is the engine that records the history of a project’s files: it stores every revision, lets contributors branch and merge work, and reconstructs any past state on demand. The VCS defines the data model (how revisions, trees, and content are stored), the history model (linear, DAG, immutable chain), and the collaboration model (centralized server-of-record vs. distributed peer clones).
This is the layer beneath the forge. git the program is a VCS; GitHub and Gitea are hosting platforms that wrap it. The two solve different problems and are evaluated in different categories.
The information on these pages was researched by a combination of human review and large language models. To suggest an addition or correction, please contact us. Prepared by Rhodium Systems Inc., author of the ResorsIT platform — a unified IT operations management platform for IT teams and MSPs that integrates a curated suite of open-source, commercial, and SaaS applications into a single system with shared identity, single sign-on, access control, and a common audit trail. Use this catalogue only as a starting point for your own research, and review any tool carefully against your own requirements before relying on it. Catalogue data version 2026.197.
Comparison
This category covers the VCS engines – the tools that define the repository format and the core commit/branch/merge semantics – as distinct from the Git hosting platforms in Git Servers & Repo Management.
The centralized, binary-asset systems (Lore, Perforce, Unity Version Control) matter only where a game or media asset pipeline is in use. Lore – Epic Games’ new MIT-licensed, content-addressed VCS announced June 2026 – is the reason this category exists: it is a peer to Git/Perforce, not a Git host.
Historic Predecessors
Two systems are carried for historical context only and are kept out of the axis tables below (they predate the concerns those tables measure – large binaries, SSO, monitoring). The lineage runs SCCS -> RCS -> CVS -> Subversion -> Git/Mercurial, with Perforce/Unity VC/Lore as the centralized binary-asset branch.
| Tool | Year | Origin | Model | Storage | Concurrency | Why superseded |
|---|---|---|---|---|---|---|
| SCCS | 1973 | Bell Labs (Rochkind) | Per-file, local | Interleaved deltas (“weave”) in an s-file | Pessimistic locking (get -e) | Per-file only; lock-serialized; no project commit |
| CVS | 1986/90 | Grune; Berliner (over RCS) | Centralized, per-file | RCS ,v files in a central repo | Optimistic copy-modify-merge | No atomic commits; no rename tracking; per-file, not changeset |
The realistic reason to touch either today is a legacy migration into Git (cvs2git, or lifting old SCCS/RCS history).
Model & Architecture
| Tool | Topology | Data Model | History Model |
|---|---|---|---|
| Lore | Centralized | Content-addressed, chunked; Merkle trees | Immutable, cryptographically-signed revision chain |
| Git | Distributed | Content-addressed object store (blobs/trees/commits) | Commit DAG; rewritable |
| Mercurial | Distributed | Revlog (per-file delta logs) | Changeset DAG; mostly immutable (phases) |
| Subversion | Centralized | Path/tree store with per-commit revisions | Linear global revision numbers |
| Perforce Helix Core | Centralized | Depot of file revisions; changelists | Linear per-depot changelist numbers |
| Unity Version Control | Centralized + distributed | Changeset + branch objects | Changeset tree; branch-per-task |
| Jujutsu | Distributed | Pluggable backend (Git default) + operation log | Change DAG with first-class conflicts; op-log undo |
| Fossil | Distributed | SQLite-backed blob store with delta compression | Commit DAG; autosync |
Large Binary Asset Handling
The decisive axis for games and entertainment workloads.
| Tool | Native Large-Binary Support | Mechanism | File Locking | Partial / Lazy Checkout |
|---|---|---|---|---|
| Lore | Excellent (by design) | Chunked content-addressed store, fragment dedup, sparse hydration | Yes (centralized) | Yes (on-demand) |
| Git | Poor (needs Git LFS) | LFS pointer files + external store | LFS file locking | Partial clone / sparse-checkout (add-on) |
| Mercurial | Moderate | largefiles / lfs extension | No native | Narrow clone (extension) |
| Subversion | Good | Stores binaries directly; no full local history | Yes (svn lock) | Yes (sparse / path checkout) |
| Perforce Helix Core | Excellent (industry standard) | Server-side revisions; streams | Yes (exclusive open) | Yes (sync only what you need) |
| Unity Version Control | Excellent | Binary-aware; Gluon for artists | Yes (exclusive locks) | Yes (partial / lazy) |
| Jujutsu | Poor (inherits Git/LFS) | Git backend + LFS | Via LFS | Via Git backend |
| Fossil | Limited | Blobs in SQLite; practical size limits | No native | No |
Branching, Merging & Workflow
| Tool | Branch Cost | Merge Engine | History Rewriting | Notable |
|---|---|---|---|---|
| Lore | Lightweight, fast switch | Server-assisted | Immutable chain | No network for local edit/commit/branch |
| Git | Cheap | Strong 3-way / recursive | Yes (rebase, amend) | The de-facto baseline |
| Mercurial | Cheap (bookmarks) + named branches | Strong | Limited (phases, evolve) | Named branches are permanent |
| Subversion | Directory copy | Historically weak; mergeinfo | No | Centralized; merges across server |
| Perforce Helix Core | Streams + per-file branches | Good | No | Stream depots model release lines |
| Unity Version Control | Cheap; branch-per-task | Strong visual merge tool | Limited | Artist + developer workflows |
| Jujutsu | Anonymous, automatic | Conflicts are first-class objects | Yes (rebase-centric, op-log undo) | No staging area; everything is a commit |
| Fossil | Branch = tag | Good | Discouraged (autosync) | “Don’t rewrite history” philosophy |
Access Control & Authentication
With Authentik as the identity provider, OIDC is preferred. Most VCS engines have no auth layer of their own – authentication is delegated to the transport (SSH/HTTPS), to a server front-end, or to a hosting forge. The binary-asset servers are the exception.
| Tool | OIDC | SAML | LDAP | Where Auth Lives | Authentik Notes |
|---|---|---|---|---|---|
| Lore | No | No | No | Built-in server access control | No external IdP at launch (June 2026) |
| Git | n/a | n/a | n/a | Transport (SSH/HTTPS) + forge | SSO is a property of the forge, not Git |
| Mercurial | n/a | n/a | via front-end | hgweb behind Apache/nginx | LDAP/SSO via the web server, not hg |
| Subversion | n/a | via front-end | via front-end | Apache (mod_dav_svn) or svnserve/SASL | Apache can delegate to LDAP/Kerberos/SAML |
| Perforce Helix Core | Paid | Paid | Native | Helix Authentication Service | HAS bridges SAML/OIDC -> Authentik possible |
| Unity Version Control | Paid | Paid | Native | Unity ID (cloud) / LDAP (on-prem) | SAML on cloud; AD/LDAP on-prem |
| Jujutsu | n/a | n/a | n/a | Git remote transport | Inherits the Git remote’s auth |
| Fossil | No | No | No | Built-in user/role table + web login | No external IdP integration |
Hosting & Ecosystem
| Tool | Forges / Hosting | CI Integration | IDE Support |
|---|---|---|---|
| Lore | None yet (CLI + full-surface API) | Via API / hooks | Early; SDKs in 6 languages |
| Git | GitHub, GitLab, Gitea, Forgejo, Bitbucket, … | Universal | Universal |
| Mercurial | Heptapod, SourceHut, self-hosted hgweb | Most CI supports hg | Good (TortoiseHg, IDE plugins) |
| Subversion | VisualSVN, Apache, legacy forges | Most CI supports svn | Good (TortoiseSVN, IDE plugins) |
| Perforce Helix Core | Helix Swarm (review), P4 ecosystem | Native plugins (Jenkins, etc.) | Strong (Unreal, game engines) |
| Unity Version Control | Unity DevOps / Unity Dashboard | Unity Cloud Build, generic | Unity Editor, Visual Studio, Gluon |
| Jujutsu | Uses any Git remote | Via Git backend | Editor support emerging |
| Fossil | Self-hosted (built-in UI); single binary | Minimal | CLI-first |
Deployment & Licensing
| Tool | License | Language | Topology | Deployment | Pricing |
|---|---|---|---|---|---|
| Lore | MIT | Rust | Centralized server | Self-host (native) | Free (OSS) |
| Git | GPL-2.0-only | C | Distributed client | Native / package | Free (OSS) |
| Mercurial | GPL-2.0-or-later | Python + Rust (core) | Distributed client | Native / package | Free (OSS) |
| Subversion | Apache-2.0 | C | Centralized client/server | Native / package | Free (OSS) |
| Perforce Helix Core | Proprietary | C/C++ | Centralized server | Native / Docker / cloud | Free <=5 users / 20 workspaces; then per-user |
| Unity Version Control | Proprietary | C# | Centralized + distributed | Cloud / on-prem | Free tier (3 users / 5 GB); then per-user + storage |
| Jujutsu | Apache-2.0 | Rust | Distributed client | Native / package | Free (OSS) |
| Fossil | BSD-2-Clause | C | Distributed (single binary) | Native / package | Free (OSS) |
Scale & Target Workload
| Tool | Practical Scale Ceiling | Sweet Spot |
|---|---|---|
| Lore | Multi-TB binary game repos (Epic scale) | Games / entertainment, code + huge assets |
| Git | Large code repos; binaries need LFS + partial clone | General software development |
| Mercurial | Very large monorepos (Meta-scale) | Large code monorepos |
| Subversion | Large centralized repos; single-server bottleneck | Centralized enterprise / legacy |
| Perforce Helix Core | Thousands of users, TB-scale depots | AAA games, film/VFX, hardware |
| Unity Version Control | Large game teams | Unity / game studios, mixed dev+artist |
| Jujutsu | Scales with its Git backend | Power users wanting better Git ergonomics |
| Fossil | Small-to-mid projects | Self-contained small-team projects (e.g. SQLite) |
Monitoring Integration
Server-based systems expose operational telemetry; pure client engines do not – their operational visibility comes from the forge or server they push to.
| Tool | Server Component | Metrics / Logs | Monitoring Fit |
|---|---|---|---|
| Lore | Yes (service-backed) | Server logs; metrics TBD (new) | Via the Lore server host |
| Git | No (client) | N/A at engine level | Observe at the forge |
| Mercurial | hgweb (optional) | Web-server logs | Via Apache/nginx front-end |
| Subversion | Apache / svnserve | Apache access/error logs | Via the front-end |
| Perforce Helix Core | p4d server | p4 monitor, structured logs, metrics | Scrape p4d host; Fluent Bit on logs |
| Unity Version Control | Cloud or on-prem server | Server logs (on-prem) | On-prem server host only |
| Jujutsu | No (client) | N/A | Observe at the Git remote |
| Fossil | Built-in server (optional) | Built-in logs / web access | Via the Fossil server host |
Tools
10 tools.
Apache Subversion
Apache Subversion (SVN) is a centralized version control system, long the enterprise standard before Git; path-based access control, atomic commits, and global revision numbers.
License: Apache-2.0 (OSS) · Kind: service · Deploy: native, package · SSO: none · Tags: vcs, centralized, cvcs
CVS
CVS (Concurrent Versions System) is a centralized version control system built atop RCS, dominant in 1990s-2000s open source; added concurrent copy-modify-merge over a central repository.
License: GPL-2.0-or-later (OSS) · Kind: service · Deploy: native, package · SSO: none · Tags: vcs, historic, centralized, cvcs
Fossil
Fossil is a self-contained distributed version control system by the SQLite project, bundling VCS, bug tracking, wiki, forum, and a web UI in a single executable.
License: BSD-2-Clause (OSS) · Kind: hybrid · Deploy: native, package · SSO: none · Tags: vcs, distributed, dvcs, self-contained
Git
Git is the dominant distributed version control system, created by Linus Torvalds in 2005 for Linux kernel development; snapshot-based with a content-addressed object store.
License: GPL-2.0-only (OSS) · Kind: cli · Deploy: native, package · SSO: none · Tags: vcs, distributed, dvcs, content-addressed
Jujutsu
Jujutsu (jj) is a Git-compatible distributed version control system with a different working-copy and change model, originally developed at Google; pluggable storage backends.
License: Apache-2.0 (OSS) · Kind: cli · Deploy: native, package · SSO: none · Tags: vcs, distributed, dvcs, git-compatible
Lore
Lore is Epic Games’ open-source, centralized, content-addressed version control system that models repository state as Merkle trees, built for code plus very large binary assets.
License: MIT (OSS) · Kind: service · Deploy: native · SSO: none · Tags: vcs, content-addressed, large-files, games, merkle
Mercurial
Mercurial is a distributed version control system emphasizing performance, a clean command set, and scalability to very large monorepos; created in 2005, used at Meta and Mozilla.
License: GPL-2.0-or-later (OSS) · Kind: cli · Deploy: native, package · SSO: none · Tags: vcs, distributed, dvcs, monorepo
Perforce Helix Core
Perforce Helix Core (P4) is a centralized version control system built for very large binary assets and monorepos, dominant in AAA game and film/VFX studios.
License: Proprietary (proprietary) · Kind: service · Deploy: native, docker, saas · SSO: OIDC, SAML · Tags: vcs, centralized, large-files, games, monorepo
SCCS
SCCS (Source Code Control System), created by Marc Rochkind at Bell Labs in 1973, was the first version control system: per-file history via interleaved deltas with pessimistic locking.
License: Proprietary (proprietary) · Kind: cli · Deploy: native, package · SSO: none · Tags: vcs, historic, centralized, local
Unity Version Control
Unity Version Control (formerly Plastic SCM) is a commercial VCS for large binary game assets offering both centralized and distributed workflows; acquired by Unity in 2020.
License: Proprietary (proprietary) · Kind: service · Deploy: native, saas · SSO: OIDC, SAML · Tags: vcs, centralized, distributed, large-files, games
