首先，我已经阅读了有关处理看似相对较小的SVN损坏的各种帖子。我发布这个是因为我们担心腐败的绝对数量意味着我们的方法存在缺陷，或者我们的恢复选择导致成功更加有限。
我们目前正在运行一个大约8年的VisualSVN 2.1.3存储库（SVN 1.6.12），在Windows文件共享上运行大约50,000个修订版，用于FSFS支持。基于VSVN历史记录，存储库的最早部分很可能是在VSVN的先前版本上运行，因为最早的版本早于当前运行的版本发布日期。
存储库有许多子项目。人们倾向于使用子树而不是整个回购。
作为升级部分内部工具和基础架构的一部分，我们遇到了各种行业标准工具，报告了回购中缺少的尾随换行问题，除非我们将它们限制在最后1500个左右的修订版中。值得注意的是，在我们运行这些工具之前，没有任何迹象表明开发团队每天都有任何问题。
所以我们开始运行svnadmin verify，它立即将第3次提交作为无效，第4次和第11次等等。在尝试手动找到好点之后，我们编写了一个脚本，在每个单独的修订版上调用svnadmin verify -r X.
最后，它报告我们的超过1,000个提交是不可验证的（我们意识到1个错误的修订也将迫使任何受影响文件的下一个版本也不可验证，至少加倍更新计数）。从8年前到大多数6年前，这些腐败分散在大部分时间线上（过去两年中有一次糟糕的提交）
此时，我们只完成了验证阶段，以确定错误的修订，但尚不清楚哪些代码受到影响。可能是所有腐败都在死亡项目/分支机构上，或者不是。
我们希望根据存储库的损坏/数量来确定推荐的方法。所有恢复选项包括升级到较新的VSVN版本并改进我们的SVN维护实践。
选项A - 增量转储/加载/比较 - 现在我们已经确定了所有不良修订，我们可以执行增量转储，跳过坏的转发。然后我们可以将这个转储加载到一个新的repo中，svn diff两个repos，看看有什么不匹配并修补剩下的差异。我们会丢失一些历史记录，但根据腐败细节，我们可以手动修补大量文件，也可能很少，具体取决于它们是否相关。但是很多手工工作。
选项B - 导出/导入 - 尝试将当前版本的repo导出到新的仓库中，丢失所有历史记录。仍然会做一个理智的比较，但不会预料到很多差异。
选项C？
谢谢！
答案 0 :(得分：0)
产生svnadmin: E160004: Revision file (rREVNUM) lacks trailing newline错误的修订版已损坏。我猜他们的修订文件是完全空的（是吗？）。如果您没有备份来恢复这些修订，则必须修复存储库。
定期验证您的存储库并实施一个非常重要 可靠的备份。为了完成这些任务并帮助Subversion管理员，最新版本 - VisualSVN Server 3.6 - 引入了built-in scheduled backup solution and scheduled verification。
为Subversion存储库设置计划存储库备份和验证只需几分钟。有关分步说明，请参阅文章KB106: Getting Started with Backup and Restore。
选项A - 增量转储/加载/比较
这种方法应该有效。但是，您应该使用空修订替换，而不是跳过那些损坏的修订版。此步骤对于确保存储库中的修订编号不会作为修复的副作用进行转换非常重要。
顺便说一句，您确实检查了存储库中的磁盘是否存在故障，对吧？如果您还没有，请运行chkdsk或类似工具。
选项B - 导出/导入
首先尝试选项A.您很可能会替换那些损坏的修订并成功修复存储库。
重要提示： VisualSVN Server 2.1.x版本系列已经过时且not supported beginning from September 2013. VisualSVN Server 2.1.x不再接收修补程序更新或安全修复程序。我们建议所有VisualSVN Server用户更新到最新的VisualSVN Server 3.6版本。升级前请阅读KB95: Upgrading to VisualSVN Server 3.6文章。