"David Glasser" <glasser_at_davidglasser.net> writes:
>> > /* 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...
Oh, I think I see what you mean now.
The use case for recovery was to make a backup into a live repository;
the idea was that the current file might be missing altogether. A
very rare window, I admit, and I'm not positive it's worth having a
recovery command for.
Now that I think about it, we could safely replace an existing current
file, if it's older than both the revs and revprops files, and those
latter two are for the same (newer) revision.
Is that what you're getting at? (...he asked, just to be sure.)
---------------------------------------------------------------------
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:22:39 CET