On 1/16/14, 6:08 AM, Olivier Berger wrote:
> (please CC: me as not subscribed)
>
> Hi.
>
> The bug report "rep-cache.db created without group write bit" [0] seems
> to be on the way of being solved (AFAIU, the fix isn't released yet).
Correct, no release includes this yet. I don't think it's been nominated
either. I'll poke Philip about his intentions here.
> I cannot seem to find a reference to a repair solution to recreate the
> contents of the DB cache (svnadmin recover doesn't address it AFAICT).
>
> The document at [1] mentions that "This file is only consulted during
> writes and never during reads. Consequently, it is not required, and
> may be removed at an abritrary time, with the subsequent loss of
> rep-sharing capabilities for revisions written thereafter." But AFAIU,
> if the file is removed, it gets recreated anyway, staring from the next
> commit, unless enable-rep-sharing = false...
>
> So I'm wondering : if the file is incomplete, is there a risk ? And
> if not, how may we recreate the contents of the cache ?
Right now there's no way to do this other than a dump/load cycle since the only
place the rep cache is written is during a commit.
For what it's worth I recall mentioning to Stefan Fuhrmann that we didn't seem
to have a way to rebuild the db and I have a hazy memory of him telling me that
we did. Looking at the code however, makes me think we don't (and I even
looked at trunk).
Now as to your comment about risk. There is no risk. If the file is missing
or incomplete it won't break anything. The only issue is that if commits are
missing then the representations they wrote cannot be used to avoid writing
identical new representations. The end result of this is that your repository
may be bigger.
> It seems that the algorithm would be quite simple from reading [1], but
> that's beyond my capacity investigating SVN internals, I'm afraid.
You're right it should be relatively easy to write some code to rebuild it (I
suspect figuring out where this functionality should go from a UI perspective
will be harder than writing the code). Even if we had functionality to rebuild
this db, if you're concerned about this it'd still probably be best to do a
dump/load. Simply because if you weren't writing the rep-cache while some
revisions were committed, then some of those revisions may contain duplicate
representations. So you repository might still be slightly bigger.
However, we ought to be able to detect that and tell you that you repo would
shrink if you ran a dump/load. In fact that might be a useful feature to
admins trying to decide if a dump/load is worth it (time vs space).
Received on 2014-01-16 20:46:43 CET