David Glasser wrote:
> 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.
There's no way to tell if it's mostly ok. I think a recover should be as robust
as a verify, without the checksum work done.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 3 03:01:07 2007