In this chapter, you have walked through most everything that you will encounter in day-to-day interaction with a Subversion repository. The first few sections walked through the basics of creating a repository, including how to get the initial files into a repository and how to check out a working copy of the repository. After that, you learned the basics of editing files and committing changes, followed by some more advanced techniques such as branching and merging. Finally, you saw how to manually merge conflicts that Subversion can't handle automatically.
This ends Part I of the book. Now that you've gone through a thorough introduction to what Subversion is and how it works, Part II will delve in depth into the workings of Subversion from the point of view of a
Part II: Subversion from a Client User's Perspective
Chapter 5. Working with a Working Copy
Chapter 6. Using Properties
Chapter 7. Configuring the Client
Chapter 8. Integrating with Other Tools
Chapter 5. Working with a Working Copy
The primary users of Subversion will almost
The framework that the developer works within, when interacting with Subversion, is a working copy of a repository. In this chapter, you will learn in detail how to interact with a working copy in order to facilitate development. In addition to fundamentals such as checking out the repository and modifying the data it contains, you will also learn details about some of the more advanced topics you may encounter in daily use of Subversion, like branching and merging.
Like most version control systems, Subversion stores versioned data in a central database, called a repository. The repository contains information about all of the versioned files and directories, including all changes to their contents over the entire history of the repository. When users want to examine or modify the data in the repository, they
5.1. The Subversion Client
When interacting with Subversion, the primary client program that you will end up using from the command line is the
command, which provides most of the features that you will need for interacting with a repository or working copy as a client
5.1.1. Common Command Options
Because many of these options are common to a variety of commands, let's take a look at them before diving into the Subversion commands themselves. The following commonly used options are common to most commands and have usage that is worth discussing before taking a look at the commands
Whenever Subversion creates a new revision, it attaches a log message to that revision that describes what changes were made in the revision, and why. Normally, Subversion will
$ svn commit --message "Fixed bug #1154."
Normally, Subversion caches your repository authorization information (username, password, etc.) as a convenience, so you don't have to type it in every time. Sometimes, though, you don't want that information to be stored. For example, you might be using someone else's workstation (or
Every Subversion command that can
$ svn revert --recursive trunk/
Many Subversion commands require you to specify a specific revision in the repository, or a range of revisions. For any command that takes a revision, you can supply it using the
option. Single revisions can be specified by following the option with a single revision number. Or, if the command takes a range of revisions, you can give two revision
$ svn log --revision 1:50
To make your life a little bit easier, Subversion also defines a few aliases that can be used to refer to certain revision numbers by their context, rather than their explicit number. Those aliases are HEAD, BASE, COMMITTED, and PREV. Each one can be used in any Subversion command, when a revision number is called foralthough BASE, COMMITTED, and PREV can only be used when referencing a working copy because they require the working copy to give them context. The HEAD alias refers to the greatest numerical revision in a repository. This is the same for every file, regardless of when they were last committed. The BASE alias, on the other hand, points to the base revision for the working copy file or directory being referenced. So, for example, if you check out the trunk directory at revision 3497, BASE would point to 3497. If you then commit a modified file inside the trunk directory at revision 3583, the BASE for that file will point to 3583, whereas the base for the trunk directory and the rest of its contents will still point to 3497. If you later update the trunk to 3583, its BASE will then point to 3583. The remaining two, COMMITTED and PREV, are then relative to the BASE revision. COMMITTED refers to the most recent commit at or before the working copy item's BASE revision, and PREV refers to the revision prior to COMMITTED. So, for instance, if you want to show the log messages from the first revision to the most recently committed revision, you could run the following command.
$ svn log --revision 1:COMMITTED
In addition to options that are common across commands, the format for specifying paths in a working copy or repository are also common. For most Subversion commands, you can reference files and directories that reside locally in a working copy or in a remote repository. Working copy files/directories are referenced by giving a local
$ svn cp http://svn.example.com/repos/trunk/foo.c~/repos_wc/trunk/bar.c