On Feb 7, 2008 7:51 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "David Glasser" <glasser_at_davidglasser.net> writes:
> >> Log:
> >> Fix issue #2992: make 'svnadmin recover' warier for FSFS.
> >>
> >> Patch by: Jeremy Whitlock <jcscoobyrs_at_gmail.com>
> >> (Tweaked by me.)
> >>
> >> * subversion/libsvn_fs_fs/fs_fs.c
> >> (recover_body): Check for missing or non-file revprops file for
> >> youngest revision, and check that maximum rev is as expected.
> >
> > Forgive me if I'm missing something (including other mail --- I'm a
> > few days behind), but I thought that making the youngest rev in the
> > current file equal the maximum discovered rev is the *entire point* of
> > FSFS svnadmin recover? If we error here, what does this command even
> > do?
>
> It's possible that the revprops file for that revision might be
> missing, since the order of writes is revs, revpros, current. So if
> we can't guarantee that all of a rev (except the current file) is
> present, we don't update the current file to point to that rev.
>
> (Or am I misunderstanding your question?)
I should have quoted the part of the diff that I meant:
/* First, we need to know the largest revision in the filesystem. */
SVN_ERR(recover_get_largest_revision(fs, &max_rev, pool));
+ /* Get the expected youngest revision */
+ SVN_ERR(get_youngest(&youngest_rev, fs->path, pool));
+
+ /* When get_youngest() returns 0, either the youngest revision truly
+ is 0 or the db/current file was recreated as part of opening the
+ filesystem for recovery. */
+ if (youngest_rev != 0 && youngest_rev != max_rev)
+ return svn_error_createf(SVN_ERR_FS_CORRUPT, NULL,
+ _("Expected youngest rev to be %ld "
+ "but found %ld"), youngest_rev, max_rev);
+
It sure seems like this is saying that if there's a current file at
all, it'll never change the rev in it... And maybe that's OK, but I
thought that was the *point* of FSFS recover...
--dave
--
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-08 04:58:54 CET