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.
Blair
---------------------------------------------------------------------
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