FSFS recovery should prune rep-cache even if its use is disabled

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