I have a Subversion working copy with at least one missing file (the local copy got removed while fixing a tree conflict). It’s funny because the file is versioned, it appears in the repository, the tree conflict resolution was 100% local (it happened on update and I didn’t commit afterwards) and I’ve run “svn cleanup” several times but none of my Subversion clients (command line svn and TortoiseSVN) can detect the working copy is corrupted. Not even reverting all changes got the file back.
I’ll fix it as usual (fresh checkout somewhere else and copy changes with WinMerge); I actually have a different question:
How can you test the validity of a working copy?
Of course, you can always check out a new copy and use a file compare utility but… isn’t there a better way? Is there a tool to verify a working copy equivalent to svnadmin verify?
=== UPDATE ===
I’ve got nice answers with tricks to prevent working copy corruption but my question was more on the line of finding a method to be 100% sure that the working copy is both coherent and linked with the actual repository contents; in other works, a working copy equivalent of the svnadmin verify command.
So far, it looks like:
-
Subversion doesn’t provide such tool and it’s possible that the SVN data format does not even allow to write one.
-
Updating to a revision is a technique that seems to find (and fix) some issues, although you often need to revert back and forth to an old revision and I suppose it can only detect missing files if they have been changed in the revision range.
-
Checking out a fresh working copy looks like the only 100% reliable method.
So far, I’ll have to assume that there isn’t a reliable way to do it unless you do a new commit and compare both directory trees. If a
.snvdirectory is missing data but is not actually damaged, there just isn’t enough information in the working copy to detect some files are gone.While it’s possible that WC-NG changes this for better (or not), current format is not that rock-solid.