首先，我已经阅读了有关处理看似相对较小的 SVN 损坏的各种帖子。我发布此消息是因为我们担心腐败的绝对数量意味着我们的方法存在缺陷，或者我们导致成功的恢复选项更加有限。
我们目前正在运行一个大约 8 年历史的 VisualSVN 2.1.3 存储库 (SVN 1.6.12)，在 Windows 文件共享上运行大约 50,000 个修订版，用于 FSFS 支持。根据 VSVN 历史，存储库的早期部分很可能在 VSVN 的早期版本上运行，因为最早的修订版本早于当前运行的版本发布日期。
该存储库有许多子项目。人们倾向于在子树上工作，而不是在整个 repo 上工作。
作为升级我们的一些内部工具和基础设施的一部分，我们遇到了各种行业标准工具，它们报告了回购中缺少的尾随换行问题，除非我们将它们限制在最近的 1500 个左右的修订版中。需要注意的是，在我们运行这些工具之前，没有任何迹象表明开发团队每天都有任何问题。
所以我们开始运行 svnadmin verify，它立即将第 3 次提交高亮显示为无效，第 4 次和第 11 次等等。在尝试手动找到好点之后，我们编写了一个脚本来调用 svnadmin verify -r X 对每个单独的修订。
最后，它报告说我们的 1,000 多个提交是不可验证的（我们意识到 1 个错误的修订也将强制任何受影响文件的下一个修订也是不可验证的，至少会使损坏计数增加一倍）。腐败分散在时间线的大部分时间，从 8 年前到大部分 6 年前（过去 2 年有一次错误提交）
- 对于大部分似乎在运行的存储库来说，这似乎相当高 - 我们的验证计划是否存在缺陷？
- 假设不是，这似乎是一个很高的数字，我们能找到的关于该主题的唯一文章暗示大提交可能是一个问题，但我们似乎比大提交更常见的问题。
在这一点上，我们只完成了验证阶段以识别不良修订，但尚不清楚哪些代码受到影响。可能所有的腐败都在死的项目/分支上，或者不是。
我们正在寻找根据损坏数量/存储库大小推荐哪种方法。所有恢复选项都包括升级到更新的 VSVN 版本和改进我们的 SVN 维护实践。
选项 A - 增量转储/加载/比较 - 现在我们已经确定了所有错误的修订，我们可以执行增量转储跳过错误的修订。然后我们可以将这个转储加载到一个新的 repo 中，svn diff 这两个 repos 并查看不匹配的内容并修补剩余的差异。我们会丢失一些历史记录，但是根据损坏的具体情况，我们可以手动修补很多文件，也可以只修补很少，这取决于它们是否相关。但是大量的手工工作。
选项 B - 导出/导入 - 尝试将当前版本的 repo 导出到新的 repo 中，丢失所有历史记录。仍然会比较理智，但不会预期会有很多差异。
选项 C？
谢谢！