Page 148 -

This version contains a change: Bob added chopped M&Ms to the recipe. This change
occurred on April 26, a few weeks before Alice checked in r47. So when it was committed,
Subversion did not complain; at the time, there were no conflicts. It simply allowed the
change and was able to update the repository without requiring any input from the user.
When May 13 rolls around and Alice tries to commit r47 in Table 7-2, Subversion discov-
ers that the working copy is out of date (because the revision number of the repository is
greater than it was when the working copy was checked out). She updates the working
copy to incorporate any changes. When she does this, Subversion detects the conflict in
line 4: the version in her working copy contains chopped nuts, while the version in the
repository contains M&Ms. Alice will then be required to decide which version of that line
should be kept; once she makes that decision, the file can be committed to the repository.
(See below for more details about how she specifies this.)

This is how the working copy allows two people to check out the same file, and even alter
the same lines in that file. They did not have to coordinate with each other, and the first
person was never even aware that a conflict occurred. It’s up to each person to resolve the
individual conflicts that arise. What’s more, a full audit trail is available, so if it turns out
that someone made the wrong choice, then that choice can be undone later and it will be
possible to figure out who made the mistake.

Access the Subversion Repository Using a URL
A Subversion repository exists on a computer as a folder. It’s easy to recognize a Subver-
sion repository: it usually contains subfolders named conf, dav, db, hooks, and locks. These
folders contain different important elements of the repository: for example, the conf folder
contains configuration files, the db folder contains a database that stores all of the files and
revision history, and the hooks folder contains scripts that can be triggered automatically
when Subversion performs certain actions.
There are two commands that are installed with Subversion that programmers will typi-
cally use to access and maintain the repository. The repository administration tool svnadmin
performs actions directly on a repository. It can create a new repository, verify its con-
tents, make a copy of an entire repository, dump the repository to a portable format,

recover from a database error, and perform other administrative tasks. svnadmin always
works on a local directory—when a user executes it, the repository is always passed as a
path to a local folder, in whatever format the operating system expects.

The command-line client tool svn is the main interface that most programmers use to
check out and update files in the repository. The svn command-line client can access a
repository using any of several different methods: accessing the folder directly on the hard
drive or a shared drive, connecting to the svnserve server, using svnserve server over SSH,
or using Apache to serve the repository via HTTP or HTTPS.

The svn client uses a URL instead of a simple path, in order to differentiate between the
different kinds of access methods. This way, the programmer using it does not need to
change the way she works in order to accommodate different kinds of access methods.
Table 7-4 shows the schema for each access method.
140 CHAPTER SEVEN