Re: Repo warped back in time after backup/restore - now what? (aka The Codehaus problem)

Holger Hoffstaette <holger@wizards.de> wrote:

> Codehaus recently had a pretty bad outage and all Subversion
> repositories had to be restored from backup.

In my experience, Subversion simply does not support such scenarios (which
makes it very bad for real enterprise deployment in fact). Have a look:
http://svn.haxx.se/users/archive-2006-05/0390.shtml

> While I have a very
> recent clean checkout (1 minute before the crash) I cannot use it
> since of course the last revision on the server has gone back in
> time.

All the working copies that point to a revision which does not exist now are
doomed. You can't do anything good with them. The only thing you can do is to
"svn diff" them to extract a patch, and then apply it to a fresh checkout.

> What are my options? Check out trunk into another tree, do a
> file-level compare (argh!) and then commit back?

Exactly.

> I'd rather not pull
> any tricks but people do have modified working copies that they
> cannot commit now, and that's pretty bad. :( Any help appreciated.

Keep also in mind that you might want to change your repository UUID.
Otherwise, when the number of revision grows, the old working copies will be
*fooled* into thinking that the revisions on the server are back. This would
make them "work" again in a way that might lead to silent corruption (because
the working copy and the server have a different BASE revision, and they only
communicate through deltas against the BASE).

I'm not sure if there's a fast way to change the UUID of a server. I went
through a full dump/load cycle creating a new server, to be sure not to do
anything wrong.

Giovanni Bajo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 20 12:25:27 2006