On Feb 7, 2008 9:22 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> "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.
A backup solution that just doesn't copy the "current" file at all
seems rather bizarre to me. Copying the current file but possibly out
of sync with the rev[prop] files makes more sense. See also Malcolm's
original justification at
http://svn.haxx.se/dev/archive-2007-03/0061.shtml.
> 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.)
I mean, that *is* what Malcolm's FSFS recover patch did, until r29175
essentially disabled it in all but the most obscure of cases. As far
as I can tell, r29175 means that we've added a bunch of extra code to
FSFS and then made it practically inaccessible.
--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 19:47:35 CET