We've mentioned already that Subversion is a modern, network-aware version control system. As we described in the section called “Version Control Basics” (our high-level version control overview), a repository serves as the core storage mechanism for Subversion's versioned data, and it's via working copies that users and their software programs interact with that data. In this section, we'll begin to introduce the specific ways in which Subversion implements version control.
Subversion implements the concept of a version control repository much as any other modern version control system would. Unlike a working copy, a Subversion repository is an abstract entity, able to be operated upon almost exclusively by Subversion's own libraries and tools. As most of a user's Subversion interactions involve the use of the Subversion client and occur in the context of a working copy, we spend the majority of this book discussing the Subversion working copy and how to manipulate it. For the finer details of the repository, though, check out Chapter 5, Repository Administration.
A Subversion client commits (that is, communicates the changes made to) any number of files and directories as a single atomic transaction. By atomic transaction, we mean simply this: either all of the changes are accepted into the repository, or none of them is. Subversion tries to retain this atomicity in the face of program crashes, system crashes, network problems, and other users' actions.
Each time the repository accepts a commit, this creates a new state of the filesystem tree, called a revision. Each revision is assigned a unique natural number, one greater than the number assigned to the previous revision. The initial revision of a freshly created repository is numbered 0 and consists of nothing but an empty root directory.
Figure 1.6, “Tree changes over time” illustrates a nice way to visualize the repository. Imagine an array of revision numbers, starting at 0, stretching from left to right. Each revision number has a filesystem tree hanging below it, and each tree is a “snapshot” of the way the repository looked after a commit.
Subversion client programs use URLs to identify versioned files and directories in Subversion repositories. For the most part, these URLs use the standard syntax, allowing for server names and port numbers to be specified as part of the URL.
Subversion repository URLs aren't limited to only
http:// variety. Because Subversion
offers several different ways for its clients to communicate
with its servers, the URLs used to address the repository
differ subtly depending on which repository access mechanism
is employed. Table 1.1, “Repository access URLs”
describes how different URL schemes map to the available
repository access methods. For more details about
Subversion's server options, see
Chapter 6, Server Configuration.
Table 1.1. Repository access URLs
||Direct repository access (on local disk)|
||Access via WebDAV protocol to Subversion-aware Apache server|
||Access via custom protocol to an
Subversion's handling of URLs has some notable nuances.
For example, URLs containing the
access method (used for local repositories) must, in
accordance with convention, have either a server name
localhost or no server name at
Also, users of the
file:// scheme on
Windows platforms will need to use an unofficially
“standard” syntax for accessing repositories
that are on the same machine, but on a different drive than
the client's current working drive. Either of the two
following URL path syntaxes will work, where
X is the drive on which the repository
Note that a URL uses forward slashes even though the
native (non-URL) form of a path on Windows uses backslashes.
Also note that when using
form at the command line, you need to quote the URL (wrap it
in quotation marks) so that the vertical bar character is not
interpreted as a pipe.
You cannot use Subversion's
in a regular web browser the way typical
file:// URLs can. When you attempt to view
file:// URL in a regular web browser, it
reads and displays the contents of the file at that location
by examining the filesystem directly. However, Subversion's
resources exist in a virtual filesystem (see the section called “Repository Layer”), and your browser
will not understand how to interact with that
The Subversion client will automatically encode URLs as
necessary, just like a web browser does. For example, the URL
http://host/path with space/project/españa
— which contains both spaces and upper-ASCII characters
— will be automatically interpreted by Subversion as if
If the URL contains spaces, be sure to place it within
quotation marks at the command line so that your shell treats
the whole thing as a single argument to the program.
There is one notable exception to Subversion's handling of
URLs which also applies to its handling of local paths in many
contexts, too. If the final path component of your URL or
local path contains an at sign (
@), you need
to use a special syntax—described in
the section called “Peg and Operative Revisions”—in order to make
Subversion properly address that resource.
In Subversion 1.6, a new caret (
notation was introduced as a shorthand for “the URL of
the repository's root directory”. For example, you can
^/tags/bigsandwich/ to refer to the
URL of the
/tags/bigsandwich directory in
the root of the repository. Note that this URL syntax works
only when your current working directory is a working
copy—the command-line client knows the repository's root
URL by looking at the working copy's metadata. Also note that
when you wish to refer precisely to the root directory of the
repository, you must do so using
the trailing slash character), not merely
A Subversion working copy is an ordinary directory tree on your local system, containing a collection of files. You can edit these files however you wish, and if they're source code files, you can compile your program from them in the usual way. Your working copy is your own private work area: Subversion will never incorporate other people's changes, nor make your own changes available to others, until you explicitly tell it to do so. You can even have multiple working copies of the same project.
After you've made some changes to the files in your working copy and verified that they work properly, Subversion provides you with commands to “publish” your changes to the other people working with you on your project (by writing to the repository). If other people publish their own changes, Subversion provides you with commands to merge those changes into your working copy (by reading from the repository).
A working copy also contains some extra files, created and
maintained by Subversion, to help it carry out these commands.
In particular, each working copy contains a subdirectory
.svn, also known as the working
copy's administrative directory. The
files in the administrative directory help Subversion
recognize which of your versioned files contain unpublished
changes, and which files are out of date with respect to
Prior to version 1.7, Subversion
subdirectories in every versioned
directory of your working copy. Subversion 1.7 offers a
completely new approach to how working copy metadata is
stored and maintained, and chief among the visible changes
to this approach is that each working copy now has only
.svn subdirectory which is an
immediate child of the root of that working copy.
For each file in a working directory, Subversion records (among other things) two essential pieces of information:
What revision your working file is based on (this is called the file's working revision)
A timestamp recording when the local copy was last updated by the repository
Given this information, by talking to the repository, Subversion can tell which of the following four states a working file is in:
- Unchanged, and current
The file is unchanged in the working directory, and no changes to that file have been committed to the repository since its working revision. An svn commit of the file will do nothing, and an svn update of the file will do nothing.
- Locally changed, and current
The file has been changed in the working directory, and no changes to that file have been committed to the repository since you last updated. There are local changes that have not been committed to the repository; thus an svn commit of the file will succeed in publishing your changes, and an svn update of the file will do nothing.
- Unchanged, and out of date
The file has not been changed in the working directory, but it has been changed in the repository. The file should eventually be updated in order to make it current with the latest public revision. An svn commit of the file will do nothing, and an svn update of the file will fold the latest changes into your working copy.
- Locally changed, and out of date
The file has been changed both in the working directory and in the repository. An svn commit of the file will fail with an “out-of-date” error. The file should be updated first; an svn update command will attempt to merge the public changes with the local changes. If Subversion can't complete the merge in a plausible way automatically, it leaves it to the user to resolve the conflict.
A typical Subversion repository often holds the files (or source code) for several projects; usually, each project is a subdirectory in the repository's filesystem tree. In this arrangement, a user's working copy will usually correspond to a particular subtree of the repository.
For example, suppose you have a repository that contains
two software projects,
calc. Each project lives in its own
top-level subdirectory, as shown in Figure 1.7, “The repository's filesystem”.
To get a working copy, you must check
out some subtree of the repository. (The term
check out may sound like it has something to do
with locking or reserving resources, but it doesn't; it simply
creates a working copy of the project for you.) For example,
if you check out
/calc, you will get a
working copy like this:
$ svn checkout http://svn.example.com/repos/calc A calc/Makefile A calc/integer.c A calc/button.c Checked out revision 56. $ ls -A calc Makefile button.c integer.c .svn/ $
The list of letter
As in the left
margin indicates that Subversion is adding a number of items
to your working copy. You now have a personal copy of the
/calc directory, with one
holds the extra information needed by Subversion, as mentioned
Suppose you make changes to
.svn directory remembers the
file's original modification date and contents, Subversion can
tell that you've changed the file. However, Subversion does
not make your changes public until you explicitly tell it to.
The act of publishing your changes is more commonly known as
committing (or checking
in) changes to the repository.
To publish your changes to others, you can use Subversion's svn commit command:
$ svn commit button.c -m "Fixed a typo in button.c." Sending button.c Transmitting file data . Committed revision 57. $
Now your changes to
been committed to the repository, with a note describing your
change (namely, that you fixed a typo). If another user
checks out a working copy of
will see your changes in the latest version of the
Suppose you have a collaborator, Sally, who checked out a
working copy of
/calc at the same time
you did. When you commit your change to
button.c, Sally's working copy is left
unchanged; Subversion modifies working copies only at the
To bring her project up to date, Sally can ask Subversion to update her working copy, by using the svn update command. This will incorporate your changes into her working copy, as well as any others that have been committed since she checked it out.
$ pwd /home/sally/calc $ ls -A Makefile button.c integer.c .svn/ $ svn update Updating '.': U button.c Updated to revision 57. $
The output from the svn update command
indicates that Subversion updated the contents of
button.c. Note that Sally didn't need to
specify which files to update; Subversion uses the information
.svn directory as well as further
information in the repository, to decide which files need to
be brought up to date.
As a general principle, Subversion tries to be as flexible as possible. One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers. Subversion working copies do not always correspond to any single revision in the repository; they may contain files from several different revisions. For example, suppose you check out a working copy from a repository whose most recent revision is 4:
At the moment, this working directory corresponds exactly
to revision 4 in the repository. However, suppose you make a
button.c, and commit that
change. Assuming no other commits have taken place, your
commit will create revision 5 of the repository, and your
working copy will now look like this:
Suppose that, at this point, Sally commits a change to
integer.c, creating revision 6. If you
use svn update to bring your working copy
up to date, it will look like this:
Sally's change to
appear in your working copy, and your change will still be
button.c. In this example,
the text of
Makefile is identical in
revisions 4, 5, and 6, but Subversion will mark your working
Makefile with revision 6 to
indicate that it is still current. So, after you do a clean
update at the top of your working copy, it will generally
correspond to exactly one revision in the repository.
One of the fundamental rules of Subversion is that a “push” action does not cause a “pull” nor vice versa. Just because you're ready to submit new changes to the repository doesn't mean you're ready to receive changes from other people. And if you have new changes still in progress, svn update should gracefully merge repository changes into your own, rather than forcing you to publish them.
The main side effect of this rule is that it means a working copy has to do extra bookkeeping to track mixed revisions as well as be tolerant of the mixture. It's made more complicated by the fact that directories themselves are versioned.
For example, suppose you have a working copy entirely at
revision 10. You edit the
foo.html and then perform
an svn commit, which creates revision 15
in the repository. After the commit succeeds, many new
users would expect the working copy to be entirely at
revision 15, but that's not the case! Any number of changes
might have happened in the repository between revisions 10
and 15. The client knows nothing of those changes in the
repository, since you haven't yet run svn
update, and svn commit doesn't
pull down new changes. If, on the other hand,
svn commit were to automatically download
the newest changes, it would be possible to set the
entire working copy to revision 15—but then we'd be
breaking the fundamental rule of “push”
and “pull” remaining separate actions.
Therefore, the only safe thing the Subversion client can do
is mark the one
foo.html—as being at
revision 15. The rest of the working copy remains at
revision 10. Only by running svn update
can the latest changes be downloaded and the whole working
copy be marked as revision 15.
The fact is, every time you run
svn commit your working copy ends up
with some mixture of revisions. The things you just
committed are marked as having larger working revisions than
everything else. After several commits (with no updates
in between), your working copy will contain a whole mixture
of revisions. Even if you're the only person using the
repository, you will still see this phenomenon. To examine
your mixture of working revisions, use the svn
status command with the
-v) option (see
the section called “See an overview of your changes” for more
Often, new users are completely unaware that their working copy contains mixed revisions. This can be confusing, because many client commands are sensitive to the working revision of the item they're examining. For example, the svn log command is used to display the history of changes to a file or directory (see the section called “Generating a List of Historical Changes”). When the user invokes this command on a working copy object, he expects to see the entire history of the object. But if the object's working revision is quite old (often because svn update hasn't been run in a long time), the history of the older version of the object is shown.
If your project is sufficiently complex, you'll discover that it's sometimes nice to forcibly backdate (or update to a revision older than the one you already have) portions of your working copy to an earlier revision; you'll learn how to do that in Chapter 2, Basic Usage. Perhaps you'd like to test an earlier version of a submodule contained in a subdirectory, or perhaps you'd like to figure out when a bug first came into existence in a specific file. This is the “time machine” aspect of a version control system—the feature that allows you to move any portion of your working copy forward and backward in history.
However you make use of mixed revisions in your working copy, there are limitations to this flexibility.
First, you cannot commit the deletion of a file or directory that isn't fully up to date. If a newer version of the item exists in the repository, your attempt to delete will be rejected to prevent you from accidentally destroying changes you've not yet seen.
Second, you cannot commit a metadata change to a directory unless it's fully up to date. You'll learn about attaching “properties” to items in Chapter 3, Advanced Topics. A directory's working revision defines a specific set of entries and properties, and thus committing a property change to an out-of-date directory may destroy properties you've not yet seen.
Finally, beginning in Subversion 1.7, you cannot by default use a mixed-revision working copy as the target of a merge operation. (This new requirement was introduced to prevent common problems which stem from doing so.)