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