Subversion

David Turner 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 to them. Subversion can manage any sort of file collection (not only source code).

Working copy

Internet Working copy Repository

Working copy

Reasons to Use Subversion

You can work more easily with other developers on software development projects. You can undo changes to obtain earlier versions of files. Subversion is well known and free. Subversion has been under development since 2000.

CVS versus Subversion

Subversion fixes problems with CVS. (See subversion book for details.) Subversion is being adopted as a replacement for CVS.

Subversion Architecture
http://svnbook.redbean.com/en/1.4/images/ch01dia1.png

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.

Differentials

previous to the previous version

previous version

current version

Atomic commits
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.

Properties
Each file and directory has a set of propertieskeys 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 character-based files. 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 store. User B gets a copy of file X from the data store. 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 As changes.

Lock-Modify-Unlock
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 wait. After locking a file, the user may forget to unlock it. Locking does not solve incompatibility problems between separate files. (See subversion book for details.)

Copy-Modify-Merge
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 As changes to X to be merged into Bs version of X. If As changes do not conflict with Bs changes, the update silently completes. If As changes conflict with Bs 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 succeeds.

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 when needed.

Revisions
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 0. After committing to a repository with revision number n, the repository is changed to version n+1.

Revisions

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 different revisions.

Revisions and Working Copies

User A checks out repository repo. repo/system.h 3 repo/system.cpp 3 User A modifies system.h and commits this file. repo/system.h 4 repo/system.cpp 3 User B commits changes to system.cpp, and A updates. repo/system.h 5 repo/system.cpp 5

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

update commit

Unchanged, and current Locally changed, and current Unchanged, and out-of-date Locally changed, and out-of-date

does nothing
does nothing

does nothing

writes changes into repo replaces working does nothing file with new one merges changes operation fails into working file with out-of-date error