[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: Karl Fogel <kfogel_at_red-bean.com>
Date: Fri, 08 Feb 2008 00:02:39 -0500

"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.

-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-08 06:02:52 CET

This is an archived mail posted to the Subversion Dev mailing list.