cloudparts

Apache Subversion

The centralized version control system that replaced CVS: one server holds the history as a single numbered sequence of atomic commits, and clients check out any directory of it.

Apache · Top-level project
What it is
Version control
Type
Open source
Made by
Apache Software Foundation
Foundation
The Apache Software Foundation, top-level project, joined November 2009
License
Apache 2.0
Facts checked
20 October 2026
Website Source code

What it is

A Subversion (SVN) repository lives on one server and records the whole tree of files and directories over time. Every commit is atomic, all of its changes go in or none do, and gets the next repository-wide revision number, so r1234 names the state of the entire tree after that commit, not of one file. Clients check out a working copy of any directory, with a hidden .svn directory that keeps each file’s original contents, so svn status and svn diff against your own edits work offline. Anything involving history (commit, log, blame, diffs between revisions) goes to the server. The default FSFS back end stores each revision’s changes in a single file on disk.

Branches and tags are just copies. svn copy of trunk to branches/fix-login takes constant time because the server stores a pointer to the existing tree, like a hard link; trunk, branches and tags are a convention, not something Subversion knows about. Because everything is a path, access control is too: path-based authorization can let one group write to a single directory and others only read it. For files that can’t be merged, such as images, svn lock gives one person the right to commit a file, and the svn:needs-lock property keeps it read-only on disk until you take the lock.

CollabNet started Subversion in 2000 as a better CVS, and it has been an Apache Software Foundation top-level project since February 2010. Git has long since overtaken it: 5% of Stack Overflow’s 2022 survey respondents used Subversion, against 94% for Git. The latest release is 1.15.0 (October 8, 2026), the first new release line since 1.14 in 2020. It can leave the original file copies out of a working copy and fetch them on demand, which its notes say cuts working-copy storage by up to 50%, and every release line is now supported for at least three years.

Why teams pick it

  • A simple model: one server, one sequence of revision numbers, and no local history to keep in sync
  • Check out just the directory you need, at whatever depth, and grant read or write access per directory
  • Locking and svn:needs-lock stop two people editing the same unmergeable binary file
  • Mature and conservative: 1.15 still works with 1.8 working copies and reads older repositories without a dump and reload

Watch out for

  • No local commits: committing, browsing history and blame all need a connection to the server
  • Subversion has no concept of a branch, only copies of directories, so branch structure is up to your team’s conventions
  • A shrinking ecosystem: GitHub removed its Subversion support in January 2024, and most tools assume Git
  • Working copies in the new 1.15 format, needed for pristines on demand, can’t be read by 1.14 or older clients

Alternatives

What all version control have in common →Compare side by side →
Perforce P4RenamedCommercialA centralized version control server built for huge repositories and big binary files, long the standard in game studios: the server knows who has every file open, can lock files exclusively, and structures branches as streams.Unity Version ControlRenamedCommercialUnity’s version control system, formerly Plastic SCM: one repository that programmers can use distributed, with branches and push and pull, while artists check files in straight to the server and lock what they can’t merge.

How it fits with other technologies

Create a repository, branch by copying, lock a binary file · bash

svnadmin create /var/svn/shop                 # a new FSFS repository
REPO=https://svn.example.com/repos/shop

svn checkout $REPO/trunk shop && cd shop
svn copy $REPO/trunk $REPO/branches/fix-login \
  -m "Branch for the login fix"              # a cheap server-side copy

svn propset svn:needs-lock yes art/hero.psd   # read-only until locked
svn lock art/hero.psd -m "Repainting the hero"
svn commit -m "New hero art"                  # one atomic revision; releases the lock

svn checkout $REPO/trunk/docs --depth immediates   # just one directory, one level deep

See it in a real stack

No architecture uses Apache Subversion yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2000–2026

By 2000 CVS was the standard open-source version control system, and CollabNet used it in its collaboration software. It wanted something better. In February 2000 it approached Karl Fogel, the author of a book on CVS, who was already discussing a new design with Jim Blandy; Blandy had coined the name Subversion and sketched the data store. CollabNet hired Fogel, and the team set out not to break new ground but to fix CVS: keep its model and features, drop its bugs and misfeatures, and make switching easy. After 14 months of coding, Subversion became self-hosting on August 31, 2001.

Version 1.0 shipped on February 23, 2004. Version 1.2 in May 2005 added optional file locking and made FSFS, which keeps revisions as plain files instead of in a Berkeley DB database, the default. Version 1.5 in June 2008 added merge tracking, and 1.7 in October 2011 replaced the scattered per-directory metadata with a single .svn directory at the root of each working copy. CollabNet brought the project to the Apache Incubator in November 2009, and in February 2010 it became a top-level project and Apache Subversion.

Git and GitHub overtook it, and GitHub turned off its Subversion support in January 2024. But at its 20th anniversary in 2020, Fogel said Subversion was still widely used, especially in enterprise settings, for its reliability, its handling of large files and its path-based authorization. Development continued: 1.15.0 arrived on October 8, 2026, more than six years after 1.14.

Why it’s built this way

Fix CVS rather than reinvent version control
CVS tracked only individual files, so it couldn’t version directories or record renames and copies, and a commit could land half-way. Subversion kept the CVS working style, check out, edit, update, commit, but versioned whole directory trees and made every commit atomic.
One revision number for the whole repository
Unlike most version control systems, whose revision numbers applied to individual files, each Subversion commit creates a new numbered state of the entire tree, so one number identifies exactly what the project looked like after any commit.
Branches and tags as cheap copies
Rather than a separate branching mechanism, Subversion makes a copy that stores only a pointer to the existing tree, in constant time. Branches and tags are then just directories, with history the same tools can show.
Add optional locking for files that can’t be merged
Merging works for text but not for images or other binaries, where two people’s edits can’t be combined. Version 1.2 added svn lock and svn:needs-lock so teams could serialize work on such files while still merging everything else.

Timeline

  1. 2000

    CollabNet starts Subversion as a replacement for CVS (February)

  2. 2001

    Subversion becomes self-hosting (August 31)

  3. 2004

    Subversion 1.0 (February 23)

  4. 2005

    1.2 adds file locking and makes FSFS the default (May 23)

  5. 2008

    1.5 adds merge tracking (June 19)

  6. 2010

    Becomes a top-level Apache project, Apache Subversion (February)

  7. 2026

    1.15.0, the first new release line since 2020 (October 8)

Sources16 · facts checked 20 October 2026

Improve this page on GitHub