Dec 24, 2007
What is Subversion?
• Subversion is a version control system.
• A version control system allows users to
manage files, directories, and the changes made
• Subversion can manage any sort of file
collection (not only source code).
Working copy Repository
Reasons to Use Subversion
• You can work more easily with other developers
on software development projects.
• You can undo changes to obtain earlier versions
• Subversion is well known and free.
• Subversion has been under development since
CVS versus Subversion
• Subversion fixes problems with CVS.
(See subversion book for details.)
• Subversion is being adopted as a
replacement for CVS.
Repository versus Working Copy
• Project code is stored in a server in a data store
referred to as a “repository.”
• Developers “check out” copies of the project
code into their local environments. These
copies are referred to as “working copies.”
• After making changes to a working copy, the
developer “commits” changes to the repository.
• Other developers get these changes by
“updating” their working copies.
∆ ∆ ∆
previous previous current
to the version version
• A collection of modifications either goes
into the repository completely, or not at all.
• In other words, a commit will either
altogether succeed, or it will altogether fail.
• Each file and directory has a set of
properties—keys and their values—
associated with it.
• You can keep certain files from being
written into the repository by setting the
svn:ignore property to a string that
matches the files you want to omit. Such
files are said to be “unversioned.”
Binary versus Character Data
• Subversion expresses file differences
using a binary differencing algorithm,
which works identically on both binary and
• Both types of files are stored in
compressed format in the repository.
• CVS treats these file types differently.
The Fundamental Problem
• User A gets a copy of file X from the data
• User B gets a copy of file X from the data
• User A changes X and writes the new X
back into the data store.
• User B changes his older version of X and
writes this into the data store, over-writing
• The lock-modify-unlock solution to the
fundamental problem has several problems:
• Two users may want to modify two separate
parts of the file, which means one user must
• After locking a file, the user may forget to unlock
• Locking does not solve incompatibility problems
between separate files. (See subversion book
• Subversion uses a copy-modify-merge approach instead of locking.
• User A gets a “working copy” of X.
• User B gets a “working copy” of X.
• User A changes his working copy of X.
• User B changes her working copy of X.
• A saves his copy of X into the repository.
• B tries to save his copy of X into the repository, but it fails, because
her changes were made to a now stale version of X
• B performs an “update,” which results in A’s changes to X to be
merged into B’s version of X.
• If A’s changes do not conflict with B’s changes, the update silently
completes. If A’s changes conflict with B’s changes, subversion
inserts annotation into X describing the conflicts and then reports the
problem to B. B then manually resolves the conflict.
• Whether B needed to manually resolve conflicts or not, the next step
is for B to commit her changes into the repository, which now
Copy-Modify-Merge in Practice
• With copy-modify-merge, users do not wait
on each other.
• In practice, conflicts are rare and are
usually straightforward to resolve.
• Copy-modify-merge does not work well
with binary files, because changes can not
be merged. For this reason, subversion
provides a lock-modify-unlock process
• Subversion transactions are atomic: they
either succeed entirely or fail entirely
• After the repository is initially created, it is
an empty folder and has revision number
• After committing to a repository with
revision number n, the repository is
changed to version n+1.
This diagram and the following text were taken from the online
version of the Subversion book.
When Subversion users talk about “revision 5 of foo.c”,
they really mean “foo.c as it appears in revision 5.”
Revisions and Working Copies
• Working copies do not always correspond
to any single revision of the repository;
they may contain files from several
Revisions and Working Copies
• User A checks out repository repo.
• User A modifies system.h and commits this file.
• User B commits changes to system.cpp, and A updates.
States of a Working File
• Unchanged, and current
• Locally changed, and current
• Unchanged, and out-of-date
• Locally changed, and out-of-date
Update and Commit
Unchanged, and does nothing does nothing
Locally changed, does nothing writes changes
and current into repo
Unchanged, and replaces working does nothing
out-of-date file with new one
Locally changed, merges changes operation fails
and out-of-date into working file with out-of-date