It looks like r1213716 ("also prune the rep-cache when it's present but 
reportedly not being used") was reverted by r1367674, apparently 
unintentionally.

https://svn.apache.org/r1213716 (on 2011-12-13)
> Follow-up to r1213681: also prune the rep-cache when it's present
> but reportedly not being used.
[...]
   /* Prune younger-than-(newfound-youngest) revisions from the rep cache. */
-  if (ffd->rep_sharing_allowed)
+  if (ffd->format >= SVN_FS_FS__MIN_REP_SHARING_FORMAT)
     SVN_ERR(svn_fs_fs__del_rep_reference(fs, max_rev, pool));

https://svn.apache.org/r1367674 (on 2012-07-31)
> Fix issue 4214, "svnadmin recover" should not create rep-cache.db.
> * subversion/libsvn_fs_fs/fs_fs.c (recover_body): Don't create rep-cache.
[...]
-  /* Prune younger-than-(newfound-youngest) revisions from the rep cache. */
-  if (ffd->format >= SVN_FS_FS__MIN_REP_SHARING_FORMAT)
-    SVN_ERR(svn_fs_fs__del_rep_reference(fs, max_rev, pool));
+  /* Prune younger-than-(newfound-youngest) revisions from the rep
+     cache if sharing is enabled taking care not to create the cache
+     if it does not exist. */
+  if (ffd->rep_sharing_allowed)
+    {
+      svn_boolean_t rep_cache_exists;
+
+      SVN_ERR(svn_fs_fs__exists_rep_cache(&rep_cache_exists, fs, pool));
+      if (rep_cache_exists)
+        SVN_ERR(svn_fs_fs__del_rep_reference(fs, max_rev, pool));
+    }

The function concerned, recover_body(), has since been moved to 
subversion/libsvn_fs_fs/recovery.c.

If "recovery" while re-sharing is disabled (by the fsfs.conf setting) leaves 
future revision entries in the rep-cache, then later re-enabling the rep-cache 
could cause serious corruption if those entries are then used.

Therefore I think we should repeat r1213716 as a bug fix.

WDYT?

-- 
- Julian

Reply via email to