Deficiency in Subversion - restore breaks working copies

["Wadsworth, Eric (Contractor)" <wa...@fhu.disa.mil>]

In the case that a subversion repository must be restored from backup, all
working copies that had updated to a revision number greater than the one
restored require extensive manual intervention to restore working order.

As has been mentioned recently, there exist techniques for getting diffs and
patching in working copies. But what if more extensive changes were made,
such as directory structure adjustmens? And still, all these must be
manually done for each working directory.

Would it be feasible to implement a mechanism that would remove the need to
have each working copy touched in order to use the restored repository? As
it stands, restoring a backed up repository, and getting all working copies
manually synched is a daunting task.

Here's a process might make sense. It's just off the top of my head.

1. The repository is lost, and the admin restores it from a backup. The
admin sets a flag in the repository indicating that a restore happened. It's
in a "restore" state. Alternately, if there was no backup, the administrator
can simply create a new empty repository (same name and path), and set the
restore flag (it will have revision number 1). Many working copies now have
revision numbers greater than that of the restored repository, rendering
them unusable.

2. When a user attempts to use a working copy against a repository with the
restore flag set, subversion checks to see if the revision number is greater
than the repository itself. If so, the user is given a message describing
the situation, and a meta-data file is created and sent into the repository
describing exactly what is different between this working copy and the
repository. The user is asked if she would like to go ahead and save her
working copy into the repository in a temporary location to preserve any
changes that happened after the time of the latest backup. She says "yes".

3. The admin checks the temporary location in the repository, and notices
that this user has added her working copy. He decides that this working copy
has some good stuff that is missing in the repository, and using the
meta-data provided in the file from step 2, replaces portions of the
repository with stuff from this temporary location in the repository. He
does this for several users who have sent in their working copies, bringing
the repository up to the best possible version. In the case that there was
no backup restored at all (just an empty repository created), the repository
can be rapidly recreated (minus historical information and revisions) from
existing working copies.

--- Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Deficiency in Subversion - restore breaks working copies

[Marcus Alanen <ma...@abo.fi>]

Wadsworth, Eric (Contractor) wrote:
> In the case that a subversion repository must be restored from backup, all
> working copies that had updated to a revision number greater than the one
> restored require extensive manual intervention to restore working order.

Just wondering out loud: what if a wc A is upto revision 200, and the 
repository is restored from backup to revision 100, THEN other 
developers pump up the version number to >200. Does wc A go completely 
wild now?

Marcus



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org