Page 144 -

number of times. When a programmer wants to update the repository with his changes,
he retrieves all changes that have occurred to the checked out files and reconciles any of
them that conflict with changes he made before updating the repository. (See below for
details about how copy-modify-merge works.)
Many programmers who have never worked with a copy-modify-merge version control
system will find it counterintuitive. The idea that multiple people can use their own work-
ing copies to work on a snapshot of the code may seem like an invitation to disaster. It
seems intuitive to him that programmers will step on one another’s toes all the time, con-
stantly overwriting changes and eventually creating an unmanageable mess.

In practice, the opposite is true: it turns out that it is usually easy to merge changes, and
that very few changes conflict. Code is almost always built in such a way that the func-
tionality is highly encapsulated in functions. And even within individual functions, there
are small, independent blocks of code. Even if two neighboring blocks are altered at the
same time, it is rare for a conflict to be introduced.
Copy-modify-merge is very efficient. Teams lose much more time from schedule bottle-
necks caused by waiting for files that are checked out than they do from trying to figure
out how to merge the changes. Giving multiple people the ability to merge changes into a
shared repository is an important way to eliminate those bottlenecks. Version control sys-
tems based on the copy-modify-merge model have been used for years on many projects.
This is especially true for large teams or teams in which the members are distributed over
a large geographical area—their work would grind to a halt waiting for people to check
code back in.

Understanding Subversion
The Subversion repository contains a set of files laid out in a tree structure (similar to the
file systems in most operating systems), with folders that contain files and other folders, as
well as links or shortcuts between files. The main difference is that the Subversion file sys-
tem tracks every change that is made to each file stored in it. There are multiple versions
of each file saved in the repository. The files in the repository are stored on disk in a data-
base, and can only be accessed using the Subversion software.

A Subversion repository has a revision number. This revision number gets incremented
every time a change is made to the repository—this way, no revision number is used more
than once. The standard convention for writing revision numbers is a lowercase “r” followed
by the number of the revision; all output from Subversion will adhere to this convention.
The Subversion repository keeps track of every change that is made to every file stored in
it. Even if a file is modified by adding or removing lines, or if that file is removed entirely,
all previous revisions still can be accessed by date or number. Subversion can also generate
a list of differences between any two revisions of a file.

For example, consider a repository that contains Revision 23 of the file cookies.txt in
Table 7-1, which was checked in on March 4.

136 CHAPTER SEVEN