How to verify Subversion working copy

Question

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.

Answer 1

If you right click on the file, under the SVN menu I believe there is a command called Diff. This will open and highlight the differences between the local version and the repo version I believe.

You can also execute diff from the command line if you wish.

Answer 2

I've had similar problems when I was beginning to work with SVN using Tortoise on Windows. Whenever I needed a to copy a folder - e.g. when creating a new plug-in that was based on another, already existing one - I merrily copy+pasted it within the working copy.

What I didn't know was that when you do that, you copy along the .svn metadata directory. This causes subversion endless confusion - if you work with a graphical client, the new directory seems to be properly checked in, and the client shows you a clean plate after each commit. But, the new directory never gets checked in.

You notice this when you check out a new working copy elsewhere, and then you're screwed because those files never were under version control. Cost me half a day to fix back then.

When you need duplicate a directory in a working copy, always export it first, then add it back.

Answer 3

This looks like a problem that I experienced some time ago: http://stackoverflow.com/questions/1711885/svn-file-in-working-copy-seems-lost

quoting wcoenen's answer verbatim:

SVN 1.6.1 clients (including TortoiseSVN) had a bug where folders would sometimes erroneously be set to depth "empty". This causes the symptoms you describe. (Note that it's possible that the folder was made "empty" by svn 1.6.1 and has remained that way even though you've already upgraded to a newer svn client in the mean time.)

To fix it, use the "update to revision" menu item in TortoiseSVN and select the depth "fully recursive"

Answer 4

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 .snv directory 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.