Re: I've messed with the repository - how to recover?

Hi Daniel,

On Wed, Sep 29, 2010 at 10:22:57AM +0200, Daniel Shahaf wrote:

> > > > It looks like there are revisions which refer to future revisions.
> > >
> > > That's... weird.
> > >
> > > > Did I
> > > > miss something? I've seen rep-cache.db hanging around - might this have
> > > > caused problems since it still contained references to revisions I've
> > > > removed? According to
> > > > http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
> > > > it is safe to remove the rep-cache.db I'd just lose representation
> > > > sharing for my testing repository, right?
> > >
> > > You will lose the ability for future revisions to re-use the reps
> > > indexed in the database. Existing rep sharing will not be affected.
> > >
> > > If you'd like to disable rep-sharing, then use the fsfs.conf file, or
> > > create a format-3 filesystem (via 'svnadmin create --pre-1.5-compatible')
> >
> > I don't want to disable rep-sharing. I just wondered whether rep-sharing
> > might have introduce these pointers to future revisions since there
> > might have been references to 115310 in rep-cache.db which got reused?
>
> Reference to rN are added to the DB at the time rN is committed.
> I don't see how forward-pointing references are possible.

Without knowing the internals of rep-cache.db I suspect something like
this (starting at rev N):
1. I commit revN -> rep-cache.db get's an entry pointing to revN
2. I commit revN+1...revN+10 -> rep-cache.db gets more entries
3. I *remove* revN...revN+10 (which is actually not expected and not
supported) -> rep-cache.db still contains references to revN...revN+10
4. I start commiting revN...revN+20 which happen to be partially similar
to my "old" revN...revN+10 -> rep-cache.db is looked up and returns some
references to not yet (anymore) existing revisions.
5. I'm screwed (which is fair since I screwed with SVN first).

> > Maybe I'll try removing >115278 again, then delete rep-cache.db, then
> > perform all those steps again...
>
> Disable rep-sharing via the config file, too. Otherwise, the DB will be
> re-created and whatever conflict you have between r115301 and r115310
> will re-surface, since both of them are inside the replayed range.

I don't think there's a rep-sharing conflict, I think there's a "don't
mess with the repository conflict". ;-)

But maybe, another sanity check of values returned from rep-cache.db
would be suitable (rev <= youngest). Just to be sure.

Thanks,

Tino.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."
www.tisc.de