A Crash Course in Subversion, Part 2, Page 6
The Subversion working copy library is designed to operate like a journaled filesystem, in that as you run commands and your client modifies the working copy, it first locks that portion of the working copy and writes out the changes to disk in the form of a log file. This means that in the event of a problem such as a power outage, an operating system crash, or the client process being interrupted somehow, the working copy will always be returned to a useful state. Should one of these problems occur, you can use the svn cleanup command to return everything to working order. svn cleanup just takes the path to your working copy as an argument (or uses the current working directory if you don't give it one) and runs through the working copy, finishing up all unfinished work and removing stray locks. Note that you should run svn cleanup only on a working copy that isn't being accessed by another Subversion client, as the cleanup code will assume that it's perfectly fine to break locks that the running client has made, which will almost certainly result in significant problems, because the locks are there precisely to keep two processes from changing that part of the working copy at the same time.
$ svn update svn:Working copy '.' locked svn:run 'svn cleanup' to remove locks (type 'svn help cleanup' for details) $ svn status L docs M docs/design.xml $ svn cleanup $ svn status M docs/design.xml $ svn update At revision 100.
Here you can see that something has happened to the docs directory of this working copy to leave it in a locked state, as the third column of its line in the svn status output is an L. Running an svn cleanup completed whatever unfinished work needed to be done for that directory, and the second svn status shows only the modified file in that subdirectory, as it should.
You've already see svn import, but there's also a command for the reverse procedure, svn export. The export command is useful when you need to release a version of your software and you don't want to include all the administrative directories from a working copy. svn export will write out a complete directory tree containing all versioned files from either a URL in the repository (with an optional revision) or a working copy path. You can think of it as an svn checkout that doesn't write out the administrative directories.
$s vn export file:///path/to/repository/tags/release-1.0 release-1.0 A release-1.0 A release-1.0/foo.c A release-1.0/main.c A release-1.0/Makefile A release-1.0/zot.c $ ls -al release-1.0 total 24 -rw-r--r-- 1 rooneg staff 0 Jul 26 20:53 . -rw-r--r-- 1 rooneg staff 0 Jul 26 20:53 .. -rw-r--r-- 1 rooneg staff 0 Jul 26 20:53 Makefile -rw-r--r-- 1 rooneg staff 76 Jul 26 20:53 foo.c -rw-r--r-- 1 rooneg staff 99 Jul 26 20:53 main.c -rw-r--r-- 1 rooneg staff 76 Jul 26 20:53 zot.c $
There isn't a whole lot to say about the output of svn export, as it's substantially similar to that of svn checkout. Just note that the directory you export to isn't a working copy—it has no administrative .svn directory, so you can't use any Subversion commands that require a working copy to function on its contents.
In this chapter you've encountered the majority of the commands you're likely to use in your day-to-day work with Subversion. You've created a repository, imported your data, checked out working copies, committed changes, merged conflicts, added and removed files and directories, worked with branches, and covered the lesser-known but still useful Subversion features such as properties. In the process, you've gained a general understanding of how to interact with Subversion and what it can do for you.
3. OK, technically, if you run this command in a working copy directory that's full of files ending in a tilde (~), you won't see anything, because the default list of global-ignores used by Subversion includes *~. To modify this list, you can edit the ~/.subversion/config file.
4. There was a fair amount of controversy when this command was named. Most Subversion developers felt that the name accurately represented the common use case, determining exactly who wrote the line of code that caused the bug they've been tracking down; thus, the canonical name is svn blame. However, a significant number felt that retaining compatibility with the name of the CVS equivalent, annotate, was a more important consideration, and a small but vocal minority felt that "blame" had a negative connotation. Thus, svn blame can also be spelled svn annotate by those whose fingers are accustomed to the CVS command, and svn praise by those who feel that "blame" is too negative.
About the Author
Garrett Rooney is a software engineer at FactSet Research Systems, in Stamford, Connecticut, where he works on real-time news feeds. Rooney attended Rensselaer Polytechnic Institute, where he managed to complete 3 years of a mechanical engineering degree before coming to his senses and realizing he wanted to get a job where someone would pay him to play with computers. Since then, Rooney completed a computer science degree at RPI and has spent far too much time working on a wide variety of open source projects, most notably Subversion.
About the Book
Practical Subversion By Garrett Rooney