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
