Subversion is a free/open source version control system. That is, Subversion manages files and directories, and the changes made to them, over time. This allows you to recover older versions of your data or examine the history of how your data changed. In this regard, many people think of a version control system as a sort of “time machine.”
Some version control systems are also software configuration management (SCM) systems. These systems are specifically tailored to manage trees of source code and have many features that are specific to software development—such as natively understanding programming languages, or supplying tools for building software. Subversion, however, is not one of these systems. It is a general system that can be used to manage any collection of files. For you, those files might be source code—for others, anything from grocery shopping lists to digital video mixdowns and beyond.
If you're a user or system administrator pondering the use of Subversion, the first question you should ask yourself is: "Is this the right tool for the job?" Subversion is a fantastic hammer, but be careful not to view every problem as a nail.
If you need to archive old versions of files and directories, possibly resurrect them, or examine logs of how they've changed over time, then Subversion is exactly the right tool for you. If you need to collaborate with people on documents (usually over a network) and keep track of who made which changes, then Subversion is also appropriate. This is why Subversion is so often used in software development environments— programming is an inherently social activity, and Subversion makes it easy to collaborate with other programmers. Of course, there's a cost to using Subversion as well: administrative overhead. You'll need to manage a data repository to store the information and all its history, and be diligent about backing it up. When working with the data on a daily basis, you won't be able to copy, move, rename, or delete files the way you usually do. Instead, you'll have to do all of those things through Subversion.
Assuming you're fine with the extra workflow, you should still make sure you're not using Subversion to solve a problem that other tools solve better. For example, because Subversion replicates data to all the collaborators involved, a common misuse is to treat it as a generic distribution system. People will sometimes use Subversion to distribute huge collections of photos, digital music, or software packages. The problem is that this sort of data usually isn't changing at all. The collection itself grows over time, but the individual files within the collection aren't being changed. In this case, using Subversion is “overkill.”  There are simpler tools that efficiently replicate data without the overhead of tracking changes, such as rsync or unison.
In early 2000, CollabNet, Inc. (
http://www.collab.net) began seeking developers to
write a replacement for CVS. CollabNet offers a collaboration
software suite called CollabNet Enterprise Edition (CEE), of
which one component is version control. Although CEE used CVS
as its initial version control system, CVS's limitations were
obvious from the beginning, and CollabNet knew it would
eventually have to find something better. Unfortunately, CVS
had become the de facto standard in the open source world
largely because there wasn't anything
better, at least not under a free license. So CollabNet
determined to write a new version control system from scratch,
retaining the basic ideas of CVS, but without the bugs and
In February 2000, they contacted Karl Fogel, the author of Open Source Development with CVS (Coriolis, 1999), and asked if he'd like to work on this new project. Coincidentally, at the time Karl was already discussing a design for a new version control system with his friend Jim Blandy. In 1995, the two had started Cyclic Software, a company providing CVS support contracts, and although they later sold the business, they still used CVS every day at their jobs. Their frustration with CVS had led Jim to think carefully about better ways to manage versioned data, and he'd already come up with not only the name “Subversion,” but also with the basic design of the Subversion data store. When CollabNet called, Karl immediately agreed to work on the project, and Jim got his employer, Red Hat Software, to essentially donate him to the project for an indefinite period of time. CollabNet hired Karl and Ben Collins-Sussman, and detailed design work began in May 2000. With the help of some well-placed prods from Brian Behlendorf and Jason Robbins of CollabNet, and from Greg Stein (at the time an independent developer active in the WebDAV/DeltaV specification process), Subversion quickly attracted a community of active developers. It turned out that many people had encountered the same frustrating experiences with CVS and welcomed the chance to finally do something about it.
The original design team settled on some simple goals. They didn't want to break new ground in version control methodology, they just wanted to fix CVS. They decided that Subversion would match CVS's features and preserve the same development model, but not duplicate CVS's most obvious flaws. And although it did not need to be a drop-in replacement for CVS, it should be similar enough that any CVS user could make the switch with little effort.
After 14 months of coding, Subversion became “self-hosting” on August 31, 2001. That is, Subversion developers stopped using CVS to manage Subversion's own source code and started using Subversion instead.
While CollabNet started the project, and still funds a large chunk of the work (it pays the salaries of a few full-time Subversion developers), Subversion is run like most open source projects, governed by a loose, transparent set of rules that encourage meritocracy. CollabNet's copyright license is fully compliant with the Debian Free Software Guidelines. In other words, anyone is free to download, modify, and redistribute Subversion as he pleases; no permission from CollabNet or anyone else is required.
在讲解Subversion为版本控制领域带来的特性时，我们会经常通过Subversion对CVS的改进进行说明。如果不熟悉CVS，了解所有Subversion的特性会有一定的困难。而如果根本就不熟悉版本控制，你就只有干瞪眼的份儿了。因此，最好首先阅读一下第 1 章 基本概念，这一章简单介绍了一些版本控制的基本思想和概念。
CVS tracks only the history of individual files, but Subversion implements a “virtual” versioned filesystem that tracks changes to whole directory trees over time. Files and directories are versioned.
A collection of modifications either goes into the repository completely or not at all. This allows developers to construct and commit changes as logical chunks and prevents problems that can occur when only a portion of a set of changes is successfully sent to the repository.
Subversion has an abstracted notion of repository access, making it easy for people to implement new network mechanisms. Subversion can plug into the Apache HTTP Server as an extension module. This gives Subversion a big advantage in stability and interoperability, and instant access to existing features provided by that server—authentication, authorization, wire compression, and so on. A more lightweight, standalone Subversion server process is also available. This server speaks a custom protocol that can be easily tunneled via SSH.
The cost of branching and tagging need not be proportional to the project size. Subversion creates branches and tags by simply copying the project, using a mechanism similar to a hard link. Thus these operations take only a very small, constant amount of time.
图 1 “Subversion's architecture”给出了Subversion设计总体上的“俯视图”。
A tool for creating, tweaking, or repairing a Subversion repository.
The first edition of this book was released in 2004,
shortly after Subversion had reached 1.0. Over the following
four years Subversion released five major new versions, fixing
bugs and adding major new features. While we've managed to
keep the online version of this book up to date, we're
thrilled that the second edition from O'Reilly now covers
Subversion up through release 1.5, a major milestone for the
project. Here's a quick summary of major new changes since
Subversion 1.0. Note that this is not a complete list; for
full details, please visit Subversion's web site at
Release 1.1 introduced FSFS, a flat-file repository storage option for the repository. While the BerkeleyDB back-end is still widely used and supported, FSFS has since become the “default” choice for newly-created repositories due to its low barrier to entry and minimal maintenance requirements. Also in this release came the ability to put symbolic links under version control, auto-escaping of URLs, and a localized user interface.
Release 1.2 introduced the ability to create server-side “locks” on files, thus serializing commit access to certain resources. While Subversion is still a fundamentally concurrent version control system, certain types of binary files (art assets, for example) cannot be merged together. The locking feature fulfills the need to version and protect such resources. With locking also came a complete “auto-versioning” implementation, allowing Subversion repositories to be mounted as network folders. Finally, Subversion 1.2 began using a new, faster binary-differencing algorithm to compress and retrieve old versions of files.
Release 1.3 brought path-based authorization controls to the svnserve server, matching a feature formerly found only in the Apache server. The Apache server, however, gained some new logging features of its own, and Subversion's API bindings to other languages also made great leaps forward.
Release 1.4 introduced a whole new tool—svnsync— for doing one-way repository replication over a network. Major parts of the working copy metadata were revamped to no longer use XML (resulting in client side speed gains), while the BerkeleyDB repository back-end gained the ability to automatically “recover” itself after a server crash.
Release 1.5 took much longer to finish than prior
releases, but the headliner feature was gigantic:
semi-automated tracking of branching and merging. This
was a huge boon for users, and pushed Subversion far
beyond the abilities of CVS and into the ranks of
commercial competitors such as Perforce and Clearcase.
Subversion 1.5 also introduced a bevy of other
user-focused features, such as interactive resolution of
file conflicts, partial checkouts, client side
management of changelists, powerful new syntax for
svn:externals feature, and SASL
authentication support for
the svnserve server.
 Or as a friend puts it, “swatting a fly with a Buick.”