Menu
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.
720
Open the SVN server, right-click on the repository and select the copy URL to clipboard (for the VIsualSVN server) and paste it on the command line. User credentials will be the same as what we set at the time of user creation. After every successful checkout operation, the output will print a revision number.
A Subversion working copy is your own private working area, which looks like any other ordinary directory on your system. It contains a COPY of those files which you will have been editing on the website.
Check out files from Subversion repositoryIn the Get from Version Control dialog, click Add Repository Location and specify the repository URL. Click Check Out. In the dialog that opens, specify the destination directory where the local copy of the repository files will be created, and click OK.
A Subversion working copy is an ordinary directory tree on your local system, containing a collection of files. You can edit these files however you wish, and if they're source code files, you can compile your program from them in the usual way.
This looks like a problem that I experienced some time ago: 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"
191
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
