October 20, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

A Crash Course in Subversion, Part 2

  • May 6, 2005
  • By Garrett Rooney
  • Send Email »
  • More Articles »

svn cleanup

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.

svn export

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.

Summary

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.

End Notes

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

Published: November 2004, Softbound, 336 pages
Published by Apress
ISBN 1-59059-290-5
Retail price: Price: $34.99
This material is from Chapter 2 of the book.





Page 6 of 6



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel