On 11/2/07, Blair Zajac <blair@orcaware.com> wrote:
> Jeremy Whitlock wrote:
> > On 10/20/07, Blair Zajac <blair@orcaware.com> wrote:
> > Not all third-party backup solutions are Subversion aware and unless
> > you perform a cold/offline backup, this is a possible situation. The
> > good thing is that "The Book" outlines this as a scenario which can be
> > expected.
> >
> >> The rev file is more important then the revprops, so presumably we wouldn't want
> >> to set current to the previous revision and loose the rev, but we should do
> >> something about missing revprops also, at least flag a large warning and provide
> >> a way to fill in some default values.
> >
> > I think any partially backed-up revision should be discarded with a
> > warning. Something along the lines of "Revision X discarded due to a
> > partial backup.". We should have no problem checking for this
> > scenario and acting accordingly. The idea here is that we make it
> > aware that the backup up to that point is fine but there was a problem
> > with that revision.
>
> Agreed. We should be clear on that the repository is good up to revision X.
>
> >> We could populate a revprops from the previous revprops and increment the
> >> timestamp by one second and fill in default svn:author and svn:log files and ask
> >> the admin to get these fields from a post-commit email. But this sounds messy.
> >
> > I agree that this is messy and I would not expect this if I were a
> > consumer. Anytime you have to "guess" what to put in place, you are
> > in a bad situation. There is no reason Subversion should be forced to
> > "clean up" after a backup problem. Besides, they should be using
> > incremental backups coupled with full backup anyways. ;)
> >
> >> I would rather see no fsfs recovery ability in svn then to have people think
> >> that using a non-svnadmin hotcopy to backup a repository is safe if they can
> >> just run recover on it.
> >
> > I think we are placing blame/ownership of this situation on Subversion
> > and it should not be. I would propose that we check for any revision
> > that is incompletely backed up, restore the repository to the revision
> > before that and then alert the user of the situation. Alerting the
> > user with the problem is a lot better than trying to get Subversion to
> > guess the missing values, getting them wrong and then having to
> > document a way to fix them. If the consumer has incremental backups
> > or commit emails, recreating the faulty revision should be no problem.
> > What do you think?
>
> That sounds good. IIRC, the current implementation does an exponential search
> for the largest missing revision, then a binary search for the largest existing
> revision.
>
> So the recover instead should do an incremental search from revision 0 to ensure
> that all revs and revprops exist. I think this is necessary because you can
> have a backup tool that backed up all the revs but was in the middle of backing
> up the revprops, or vis-versa.
I dunno, I kind of feel like verify can be slow but recover ought to
be able to finish in a reasonable amount of time if the repository is
mostly OK.
--dave
--
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 2 21:59:01 2007