When Subversion modifies your working copy (or any
.svn), it tries to do
so as safely as possible. Before changing the working copy,
Subversion writes its intentions to a log file. Next it
executes the commands in the log file to apply the requested
change, holding a lock on the relevant part of the working
copy while it works — to prevent other Subversion clients
from accessing the working copy in mid-change. Finally,
Subversion removes the log file. Architecturally, this is
similar to a journaled filesystem. If a Subversion operation
is interrupted (if the process is killed, or if the machine
crashes, for example), the log files remain on disk. By
re-executing the log files, Subversion can complete the
previously started operation, and your working copy can get
itself back into a consistent state.
And this is exactly what svn cleanup
does: it searches your working copy and runs any leftover
logs, removing working copy locks in the process.
If Subversion ever tells you that some part of your working copy
is “locked”, then this is the command that you
should run. Also, svn status will display
L next to locked items:
$ svn status L somedir M somedir/foo.c $ svn cleanup $ svn status M somedir/foo.c
Don't confuse these working copy locks with the ordinary locks that Subversion users create when using the “lock-modify-unlock” model of concurrent version control; see The three meanings of “lock” for clarification.