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

Re: svn commit: r29175 - in trunk/subversion: libsvn_fs_fs tests/cmdline

From: David Glasser <glasser_at_davidglasser.net>
Date: Thu, 7 Feb 2008 21:14:50 -0800

On Feb 7, 2008 9:02 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "David Glasser" <glasser_at_davidglasser.net> writes:
> > 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...
>
> No, I don't think it's saying that. I think it's talking about the
> circumstances in which the 'current' file can contain "0": there are
> two such circumstances, and in one of them we're willing to rewrite
> 'current' with a new revision.

Sure, but I'm not talking about when the current files contains "0"; I
mean every other case...

--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 06:14:59 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.