Blair Zajac wrote:
> I was messing around with fsfs recovery today and if you remove the
> latest revprops file and current file, then the recovery will set
> current to that revision even though you can't get the revision
> properties from that file. So the repository is broken.
>
> I could see this happening with a race between the non-'svnadmin
> hotcopy' program backing up the rev file but not the current or revprops
> file during a commit, which seems possible given that fsfs writes the
> rev, revprops and then the current file in that order.
>
> The rev file is more important then the revprops, so presumably we
> wouldn't want to set current to the previous revision and loose the rev,
> but we should do something about missing revprops also, at least flag a
> large warning and provide a way to fill in some default values.
>
> We could populate a revprops from the previous revprops and increment
> the timestamp by one second and fill in default svn:author and svn:log
> files and ask the admin to get these fields from a post-commit email.
> But this sounds messy.
>
> I would rather see no fsfs recovery ability in svn then to have people
> think that using a non-svnadmin hotcopy to backup a repository is safe
> if they can just run recover on it.
Opened issue 2992 just to ensure that this doesn't get dropped.
The more I think about this, the use case this is trying to solve isn't well
defined. There's no telling what files a non-svn aware backup program may have
backed up, so you could have revs/123 and revprops/123 but revprops/99 missing
because the backup program sorts alphabetically, so the recover will run but the
verify won't.
I think we should just say that we don't promise anything with any non-svn aware
backup program. Even the Berkeley DB recover just replays log files that should
be there, it doesn't try to work around a missing log file.
Recover could check the existence of each and every revs and revprops until it
finds a missing file and uses that for current, I think I would be fine for
that, but the recovered current could be many revisions behind the HEAD revision.
I'm thinking that we should roll this code back, unless we have a good use case
where it works 100% of the time.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 24 21:17:31 2007