blair_at_tigris.org writes:
> This feature is not in 1.4, it's new code in 1.5.
>
> I do think it should be pulled since it may leave a false impression
> that you have a good repository.
[I've moved discussion from the issue tracker to the mailing list.]
Blair is talking about having 'svnadmin recover' work on FSFS
repositories. Background: I recently applied Jeremy Whitlock's patch
for issue #2992, which made FSFS recovery do better error checking.
But Blair argues above, and in more detail in the issue, that we
should not have a recovery feature for FSFS repositories at all.
I (tentatively) think we should. The final three things an FSFS
commit does are, in order:
- write the 'revs/FOO' file (atomically)
- write the 'revprops/FOO' file (atomically)
- write the 'current' file (atomically)
If recovery sees both 'revs/FOO' and 'revprops/FOO', it can recreate
'current'. Given that the vast majority of non-svn-aware backup
programs will work by just copying everything in no particular order,
then it will sometimes happen that a repository will be missing
everything but 'current'. In that case, we can recover and should;
and if we're missing more than just 'current', recovery should fail,
(which is what Jeremy's patch for issue #2992 ensures).
So with that patch applied, I think FSFS recovery is both useful (for
the race-condition case) and safe (in other cases, recovery will fail,
which is what we want).
One could argue that merely offering the feature creates a "moral
hazard" -- that admins will think any old backup tool is fine, because
the repository can always be recovered. But they won't think that for
very long, once they discover that not everything can recovered from,
and we can help that by documenting it. It seems to me that if we
have an easy way to fix one particular kind of repository breakage, we
should offer it.
[None of this affects the correctness of Jeremy's patch. If we remove
the feature, then his patch goes away along with the code it applied
to. Therefore, I've resolved issue #2992; what we're having now is a
separate discussion.]
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-04 07:05:52 CET