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

Re: [Issue 2992] fsfs svnadmin recover may leave repository in a broken state

From: David Glasser <glasser_at_davidglasser.net>
Date: Mon, 4 Feb 2008 09:22:04 -0800

On Feb 4, 2008 8:35 AM, Blair Zajac <blair_at_orcaware.com> wrote:
> Karl Fogel wrote:
> > 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.
> The type of breakage this code is handling is very rare. When is svn going to
> crash between moving revprops/FOO into place and moving current into place?

I haven't had a chance to read the rest of this issue/thread, but:

FSFS is pretty clear on this point. Crashing between moving
revprops/FOO into place and moving current into place is quite
possible. However, the semantics there are also very well defined:
the commit *didn't happen*. If current hasn't been updated, then the
commit hasn't happened yet; no user should have been told that that
revision was committed successfully; etc. I don't see why we should
add "recovery" code that makes it look like a commit has happened when
it never did!


David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
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 18:22:16 CET

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.