What is Subversion best-practice for harvesting from invalid working copies following restoration of an old repository backup?

Question

I have some questions about restoring to an old subversion repository backup.

Suppose that there are various working copies (wc) based at a revision in a certain repository (repo). The repository might be at revision 100, say, and the working copies BASEd at various revisions, say 80, 60, 40:

repo @100
wc-1 @80
wc-2 @60
wc-3 @40

Now suppose that there's a disaster, the repository is lost, and the most recent valid backup available is a bit old, say to revision 50. This is restored, and the situation is now this:

repo @50
wc-1 @80 X
wc-2 @60 X
wc-3 @40 ?

The working copies marked 'X' are now obviously invalid. Their BASE does not exist.

It is not possible to down-date (i.e. update downwards) the invalid working copies, as the required delta no longer exists in the repository. It would not be desirable to do this in any case, as such working copies might be the only existing source of the lost revisions.

Further, suppose that following the restoration of the repository, there is no process in place, and the following is allowed to happen.

Working copy 3 is apparently fine. (Well, it really is fine when considered in isolation, but perhaps it should not be touched until things have been sorted out globally.)

Its owner now gets up-to-date, and commits several sets of changes, bringing the repository's HEAD revision to 70. The situation is now this:

repo @70
wc-1 @80 X
wc-2 @60 X!
wc-3 @70 ?

Working copy 2 is now in a confused state. The revision 60 of its BASE is not the same as it was originally. However, it may not be obvious that it is invalid. The apparent differences between this working copy and the repository are a mixture of real local changes, of differences introduced by working copy 3, and differences representing the lost revisions. That is, it's a mess.

So my questions are as follows:

(1) How well does SVN behave in this respect? Specifically, how will SVN respond to wc-1's attempts to commit? How will SVN respond to wc-2's attempts to commit (once the repository HEAD is beyond wc-2's BASE)? Is this documented anywhere?

(2) Are there documented best-practice procedures for restoring to an old SVN repository backup, for identifying invalid working copies, and for trying to "harvest" the lost changes from the various invalid working copies that exist?

(Presumably, part of the answer is that as soon as a repository has been recovered, all invalid working copies should be abandoned as working copies, and their changes transferred to fresh checkouts, and that all working copies should be put on hold until a recovery plan is in place.)

Thanks.

Answer 1

Maybe I am missing something but I do not see a problem here.

User with working copy which is at revision 80 does the following

1. Leaves this working copy untouched (this is the "pristine" wc)
2. Checks out a new working copy which is at a lower revision (e.g. 50 or 70) (this is clone wc)
3. Copies manually all files from the pristine wc to the clone wc
4. Commits all changes from the clone wc to the "recovered" repository

All other users checkout (after this is done) to a completely new wc. All other wc can be discarded (the ones before the disaster).

Now everybody is at "revision 80" (in reality 51 or 71) which is the best possible scenario since this was the higher revision after the disaster.

The point is that regardless of numbers everybody gets the best/latest version of files available.

This way you don't even have to care on how "subversion behaves in this respect"