[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: fsfs recover and missing revprop

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-11-02 19:30:53 CET

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

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.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 2 19:31:10 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.