Subversion: The Centralized Version Control Model

A version control system (VCS) records the history of a set of files: every change, who made it, when, and why. It lets a team work on the same codebase without overwriting each other, roll back to any past state, and see exactly what changed between two points in time.

Git dominates today, but it is not the only model, and it was not the first to win widely. Apache Subversion (SVN), released in 2000 to replace the older CVS, was the default version control system for a large part of the industry through the 2000s. Understanding SVN is worth it for two reasons: a lot of long-lived code still lives in it, and seeing a second model makes what Git chose, and why, much clearer. This cursus covers SVN on its own terms.

This is the one distinction everything else follows from.

SVN is centralized. There is a single central repository on a server that holds the full history. Each developer checks out a working copy: the files at one revision, plus a little bookkeeping, but not the project's history. To commit, to see the log, or to branch, you talk to the server.

Git is distributed. Every developer clones the entire repository, history and all, onto their machine. Commits, branches, and history browsing happen locally; you sync with others by pushing and pulling.

That single choice explains the rest: SVN's need for connectivity, its single authoritative history, its global revision numbers, and its fine-grained server-side access control all fall out of keeping the one true repository on a server.

Picture the two models side by side. In SVN, every developer's working copy connects to one central repository that holds all history; nothing is complete without the server. In Git, every clone is a full repository in its own right, and developers sync peer-style through a shared remote by choice, not necessity.

In SVN you start by pointing at a repository URL and running a checkout. That downloads a working copy: the current files plus a hidden .svn directory at the root that records which revision you have and what you have changed locally.

svn checkout https://svn.example.com/repos/acme/trunk acme
cd acme
# ... edit files ...
svn status      # what have I changed?
svn commit -m "Fix invoice rounding"

A few things to notice. The URL is central and authoritative; there is exactly one of it. The working copy is a snapshot at one revision, not the whole timeline, so browsing deep history means asking the server. And unlike Git's clone, checking out a huge project does not drag its entire past onto your disk, which matters when a repository holds years of large binary assets.

Here is a genuinely different design choice. In SVN, a revision is a number that names the state of the entire repository after a commit. The first commit is revision 1, the next is revision 2, and so on. Revision 4217 is a single, whole-tree snapshot of the project.

Git, by contrast, identifies each commit with a content hash like a3f9c2e, and there is no single increasing counter across the project. SVN's global integer has real ergonomic value: you can say "the bug appeared in r4217" and everyone knows exactly which repository-wide state you mean, in order, without ambiguity. Because the numbers are sequential, comparing revision N with N-1 gives you precisely the change that one commit introduced. The tradeoff is that this only works because there is one central authority handing out the next number.

SVN commits are atomic: a commit either fully succeeds or has no effect at all. If you commit changes to twelve files and the connection drops midway, the repository does not end up with six of them applied. Nobody doing an update ever sees a half-finished commit.

This sounds obvious, but SVN's predecessor CVS did not guarantee it, and the lack caused real corruption and confusion. Atomicity is why a revision number can stand for a coherent whole-tree state: every revision is a complete, consistent point you can check out, build, and trust. It is one of the core reasons SVN was considered a serious upgrade over CVS when it arrived, and it remains a property teams rely on for reproducible builds tied to a revision.

Git won the general case, but centralization is a feature in some settings, and that is why SVN persists. Reported adopters of SVN include large organizations such as LinkedIn, NASA, Siemens, and Citigroup, per a 2025 RhodeCode review of version control usage. Three reasons recur:

• Large binary assets. Git stores full snapshots and struggles as binary blobs accumulate; SVN handles large, non-mergeable files more gracefully, which is why game studios and CAD/media teams favor it.
• Granular access control. Because the repository is central, you can grant a contributor read or write access to specific subdirectories. Git's model is essentially all-or-nothing per repository.
• A single source of truth. One authoritative repository, one linear revision history, one simple mental model, which some enterprise, government, and financial teams prefer.

SVN is a deliberate fit for these, not a legacy accident.

A compact comparison to anchor the model before the next lesson digs into the daily workflow:

Neither column is simply better. Git optimizes for distributed, offline, branch-heavy development; SVN optimizes for a controlled central authority with fine-grained access and large assets. Knowing both makes you effective wherever the code actually lives. Next: the day-to-day SVN commands.