> 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.
I missed a step: Once the sysadmin is happy with the repository, he removes
the "restore" flag.
Also, there are some issues not addressed here, such as what about the user
who didn't send in his working copy until after the admin released the
"restore" flag, and so is out of sync. And I don't think you can trust
revision numbers to always be good indicators of state; strange things could
happen when you get two restores in rapid succession, stuff like that.
Greater minds than mine will surely find all sorts of holes in my idea. ;)
--- Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Aug 14 17:55:08 2003