The Third Era of Version Control

Each generation of VCS answers the engineering reality of its time. CVS answered teams. SVN answered scale. Git answered distribution. Aura answers agents.

Version control is not one history. It is a sequence of distinct paradigms, each replaced when the workload outgrew it. To understand why Aura exists as its own era rather than a fork or a fashion, it helps to walk the arc.

Era 0: The pre-history (before 1990)

Before version control was a discipline, it was a convention: tar archives named project-v1.tgz, project-v2.tgz, project-v2-FINAL.tgz, project-v2-FINAL-actually.tgz. Single developers kept directory copies. Small teams emailed patches. Mainframe shops used ad-hoc tools like SCCS (1972) and RCS (1982), which versioned individual files but had no concept of a project.

RCS is worth naming because it introduced the first widely-used primitive: the reverse delta. Store the latest version in full; store older versions as patches backward. This primitive survived into every subsequent system, Git included.

Era 1: CVS (1990)

CVS — the Concurrent Versions System — was the first tool that treated a project as the unit of version control. It layered on top of RCS to allow multiple developers to check files in and out of a shared central repository.

CVS answered the engineering reality of its time: teams had grown past one developer, and shared filesystems had grown past one machine. The dominant code artifact was a Unix tarball, and the dominant workflow was FTP-plus-patches. CVS offered something better: a central server, per-file history, and a vague notion of atomic commits (per-file, not per-changeset — a flaw that would bite later).

Key characteristics:

  • Centralized.
  • File-level history.
  • No atomic project-wide commits.
  • Branching was expensive and painful.
  • Conflicts were line-level.

CVS was good enough for about a decade. Then the web happened, teams grew, and CVS's lack of atomic commits and first-class branching became unbearable.

Era 2: SVN (2000)

Subversion — SVN — was a from-scratch rewrite of CVS with the explicit goal of fixing its known limitations while preserving its mental model. SVN gave projects atomic commits across all files, proper directory versioning, cheap branches and tags (as copies), and a cleaner network protocol.

SVN answered the engineering reality of bigger teams, faster release cadences, and the emerging practice of continuous integration. The late 1990s and early 2000s saw the rise of Apache Software Foundation, Eclipse, and enterprise Java, all of which needed coordination across hundreds of developers. SVN scaled to those teams in a way CVS could not.

Key characteristics:

  • Still centralized (one blessed server).
  • Atomic project-wide commits.
  • Cheap branches (copy-on-write).
  • Global revision numbers.
  • Line-level conflicts, but with better tooling around them.

SVN was the dominant VCS from roughly 2002 to 2010. It was boring, reliable, and fit the shape of organized enterprise software.

Era 3: Git (2005)

Git was born in a two-week burst of kernel-community frustration. The Linux kernel had been using BitKeeper, a proprietary distributed VCS, and when licensing conflicts erupted in 2005, Linus Torvalds wrote Git to replace it.

Git answered the engineering reality of open-source software at global scale: thousands of contributors, no central authority, wildly asynchronous collaboration, and a need for cryptographic integrity across untrusted networks. The Linux kernel could not wait for a round-trip to a central server for every commit. It needed every clone to be a full repository.

Git's innovations were not incremental. They were a new object model:

  • Content-addressed storage: every blob, tree, and commit is hashed. Identity is content.
  • Distributed by default: every clone is complete. There is no privileged server.
  • Cheap branches: a branch is a pointer to a commit. Creating one costs nothing.
  • Merkle-tree integrity: the hash of a commit covers its entire history.
  • Three-way merge by default: text-level, but with a proper common-ancestor computation.

Git was not immediately dominant. For the first five years, Mercurial was a serious rival (and arguably better designed). What tipped the balance was GitHub, launched 2008, which turned Git's distributed model into a social network for code. By 2013, Git was the default. By 2020, it was essentially the only VCS most developers had ever touched.

Key characteristics:

  • Distributed.
  • Content-addressed by byte hash.
  • Line-level diff and merge.
  • No concept of logical structure in code.
  • Excellent for human-scale, human-paced authorship.

Git was the right tool for its era, and its era lasted twenty years — the longest reign of any VCS paradigm so far.

Interlude: the reforms

Between Git's rise and Aura's arrival, several systems tried to improve on Git without fully replacing its model. They are worth naming because they mark the edges of what the Git paradigm can do.

Mercurial (2005)

Born the same month as Git, Mercurial offered a cleaner command surface and a more disciplined object model. It lost to Git on social momentum, not technical merit. Still used at Facebook/Meta, which built Sapling on top of it.

Pijul (2014) and patch theory

Pijul is an academic-grade VCS based on the theory of patches, which treats commits as commutative operations. Mathematically elegant. Offers better conflict semantics for reordered patches. Still line-level at the primitive, no AI story, and a small community.

Sapling (2022, Meta)

Meta's open-source release of their internal Mercurial fork. Excellent monorepo ergonomics, great stacked-diff workflow, git-compatible. Still fundamentally line-based. No semantic layer.

Jujutsu / jj (2023, Google)

A modern front-end that is Git-compatible on the wire but introduces an operation-log model and a cleaner branching story. Influential, rapidly growing. Still line-level at its core. No semantic layer.

Spork, astii, and AST-merge research (ongoing)

A handful of research tools and plugins have explored AST-level merge for specific languages — Spork for Java, astii for C. They solve a real problem but only within one language and without a full VCS around them. Aura takes the same idea and generalizes it to a cross-language, whole-VCS paradigm.

The pattern: every reform stayed inside the text-diff paradigm. They made Git-like VCS better at being Git-like. None of them changed the primitive.

Era 4: Aura (2026)

Aura is the first VCS whose primitive is not text.

The primitive is the logic node — a function, class, method, or other AST-level unit — identified by the content hash of its normalized syntax tree. Every operation in Aura is defined against this primitive:

  • A diff is a delta between two logic graphs.
  • A merge is a graph reconciliation.
  • Identity is AST-content, so renames and moves are free.
  • History is a sequence of logic-graph states, each annotated with validated intent.
  • Collaboration is graph synchronization, not file synchronization.

Aura answers the engineering reality of the mid-2020s: AI agents write most new code, they refactor aggressively, they run in parallel, and they produce conflicts at an order of magnitude higher rate than humans. It also answers the adjacent realities: data sovereignty demands on European and regulated teams, the need for cryptographic audit trails as AI-authored code enters production, and the explosion of per-tool integrations that demands a universal coordination substrate.

Key characteristics:

  • Semantic primitive (logic nodes, not bytes).
  • AST-level diff and merge, cross-language via tree-sitter.
  • Intent validation at commit time.
  • Agent-native (Sentinel protocol, MCP server).
  • Sovereign by default (Mothership, self-hosted, Apache 2.0).
  • Git-compatible for incremental adoption.

The pattern across eras

Each era replaced the prior one when the primitive broke. CVS broke on atomic commits. SVN broke on distributed collaboration. Git broke on AI-scale refactoring. The replacement in each case was not a polish job — it was a new primitive:

| Era | Years | Primitive | Collaboration model | Breaks when... | |-----|-------|-----------|---------------------|----------------| | CVS | 1990–2000 | File | Centralized, locking | Atomic commits are needed | | SVN | 2000–2010 | Changeset | Centralized, coordinated | Distribution is needed | | Git | 2005–2026 | Byte-addressed blob | Distributed, text-merged | Semantic refactors collide | | Aura | 2026– | Content-addressed logic node | Distributed + P2P sync + agent coordination | (we'll find out) |

There is no reason to believe Aura is the final era. There will be a fifth. Perhaps when code stops being written in files at all, and becomes a live graph that both humans and agents edit in place. Aura's design anticipates that future — the repository is already a graph — but the era it answers is this one.

Why "Aura" and not "Git 3.0"

A reasonable question: why not build this as a Git extension, or a fork, or a wire-compatible alternative like jj? The answer is that the primitive has to change, and a change of primitive cannot be a backward-compatible reform. You can put an AST-aware merge driver into Git, and several projects do, but you cannot make Git's object model treat a function as a first-class entity without rebuilding the object store. At that point you have a new system, and it should be honest about being one.

Aura is honest. It is git-compatible at the workflow layer — you can run aura alongside git in the same repository — but its object store is its own. Its identity model is its own. Its merge engine is its own. The compatibility is ergonomic, not architectural. This is how eras transition: a period of coexistence, then a handoff.

Reading the arc forward

If the pattern holds, Aura's era is just beginning. The adoption curve of Git took roughly eight years to go from "niche" to "default." Aura launched in 2024. By the mid-2030s, if the thesis holds, semantic version control will be the substrate that every IDE, every CI/CD pipeline, and every AI agent assumes. Text-diff VCS will still exist, the way SVN still exists — maintained, boring, unfashionable, and slowly shrinking.

That is the bet. The bet is that the era has turned, and the tools will turn with it.

Next

Up next

Aura vs Git

Text-diff vs AST-diff. Blob-hashing vs content-addressed logic. Where the two differ.