Now that we've covered the day-to-day tasks that you'll frequently use Subversion for, we'll review a few administrative tasks relating to your working copy.
Subversion doesn't track either the state or the existence of working copies on the server, so there's no server overhead to keeping working copies around. Likewise, there's no need to let the server know that you're going to delete a working copy.
If you're likely to use a working copy again, there's nothing wrong with just leaving it on disk until you're ready to use it again, at which point all it takes is an svn update to bring it up to date and ready for use.
However, if you're definitely not going to use a working
copy again, you can safely delete the entire thing using
whatever directory removal capabilities your operating system
offers. We recommend that before you do so you
svn status and review any files
listed in its output that are prefixed with a
? to make certain that they're not of
When Subversion modifies your working copy—either your files or its own administrative state—it tries to do so as safely as possible. Before changing the working copy, Subversion logs its intentions in a private “to-do list”, of sorts. Next, it performs those actions to effect the desired change, holding a lock on the relevant part of the working copy while it works. This prevents other Subversion clients from accessing the working copy mid-change. Finally, Subversion releases its lock and cleans up its private to-do list. Architecturally, this is similar to a journaled filesystem. If a Subversion operation is interrupted (e.g, if the process is killed or if the machine crashes), the private to-do list remains on disk. This allows Subversion to return to that list later to complete any unfinished operations and return your working copy to a consistent state.
This is exactly what svn cleanup does:
it searches your working copy and runs any leftover to-do
items, removing working copy locks as it completes those
operations. If Subversion ever tells you that some part of
your working copy is “locked,” run svn
cleanup to remedy the problem. The svn
status command will inform you about administrative
locks in the working copy, too, by displaying
L next to those locked paths:
$ svn status L somedir M somedir/foo.c $ svn cleanup $ svn status M somedir/foo.c
Don't confuse these working copy administrative locks with the user-managed locks that Subversion users create when using the lock-modify-unlock model of concurrent version control; see the sidebar The Three Meanings of “Lock” for clarification.