Tino Schwarze wrote on Wed, Sep 29, 2010 at 11:47:08 +0200:
> 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).
>
Ah, right. Forgot to say: if you decrement current, then you MUST also
remove from rep-cache.db references to those revisions you've obliterated!
I leave this as an exercise for the reader... (the lazy reader can just
rm rep-cache.db and be fine)
> > > 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". ;-)
>
Yeah, that too. SVN_ERR_Dont_Do_That or something.
> But maybe, another sanity check of values returned from rep-cache.db
> would be suitable (rev <= youngest). Just to be sure.
>
Pretty trivial to code, but I'm not sure how much effort we should
invest in these "Let's protect someone who messed up with 'current' from
themselves" checks. Feel free to poll other devs for their opinions,
though.
> Thanks,
>
> Tino.
>
> --
> "What we nourish flourishes." - "Was wir nähren erblüht."
>
> www.tisc.de
Received on 2010-09-29 12:25:19 CEST