How to recreate rep-cache.db if it wasn't writable for some time ?

[Olivier Berger <ol...@telecom-sudparis.eu>]

(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).

So, until then, for new repositories where no commit was made, a workaround
is to create (touch) the file before the first commit.

But if commits have been made already, as the file was created with
wrong permissions, there are chances that some commits are missing.

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 ?

It seems that the algorithm would be quite simple from reading [1], but
that's beyond my capacity investigating SVN internals, I'm afraid.

Thanks in advance.

Best regards,

[0] http://subversion.tigris.org/issues/show_bug.cgi?id=3437
[1] http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Re: How to recreate rep-cache.db if it wasn't writable for some time ?

[Ben Reser <be...@reser.org>]

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