Section 5.8. Troubleshooting the Working Copy

5.8. Troubleshooting the Working Copy

Subversion is a robust, stable system, but occasionally problems do occurusually as a result of an interrupted command or unstable network connection. If such an interruption does occur, Subversion may leave active lock files in your working copy, which could block subsequent commands from being able to execute. If this happens, you may have to explicitly force Subversion to clean up after itself.

You can tell Subversion to clean up all extraneous working copy lock files by running the svn cleanup command. When the cleanup command is run, it will go through the working copy (or part of a working copy) specified on the command line, completing all unfinished actions and removing all lock files.

 $ svn cleanup repos/trunk 

If the svn cleanup command doesn't solve your problems, you may need to clean things up on the repository side (or have your repository administrator do it). The commands and techniques for doing repository troubleshooting are explained in Chapter 10, "Administrating the Repository."

In a worst-case scenario, your working copy could get irretrievably corrupted (most likely through disk error or a bug in Subversion). If this happens, you may have to delete and recheck out a working copy. In general, this is not a tragic solution, but you may have to take a few extra steps to avoid data loss if you have any uncommitted local modifications.

The best way to approach a delete-checkout solution is to first use the svn status command (if possible) to figure out which files have been locally modified. Then, make sure those are backed up somewhere outside the working copy (by copying them). When all of your local data has been saved, remove the working directory and run svn checkout to get a fresh working copy. Then, you can copy the backed up files into your new working copy and be ready to commit again.