如何正确处理git-svn中的提交断层？寻求规范解决方案

看来你在处理SVN提交r666的异常时遇到了麻烦，当前的临时方案代价有点大——放弃历史还要维护两个仓库，确实不够高效。下面给你几个更规范的解决思路，既能解决问题又能保留完整历史：

1. 先定位并修复异常根源 #

首先得搞清楚r666到底出了什么问题，是提交内容本身有问题，还是SVN仓库的元数据损坏？

• 如果是提交的文件内容异常（比如误提交大文件、二进制文件损坏），直接用反向合并撤销：svn merge -c -666 .，然后提交一个新的版本来抵消r666的变更，这样完整保留所有历史记录，团队成员也能清晰看到修正轨迹。
• 如果是仓库元数据损坏，先试试用svnadmin verify检查仓库完整性，再用svnadmin recover修复。要是远程仓库，得联系运维同学操作；本地仓库的话直接在仓库根目录跑命令就行。

2. 选择性迁移仓库（保留历史跳过异常提交） #

如果r666的异常没法直接修复，但又不想丢之前的历史，可以用SVN的导出导入工具来做精准迁移：

• 先导出r665及之前的完整历史：svn dump http://your-svn-repo -r 1:665 > pre-666-dump.dump
• 再导出r667及之后的增量历史（如果后续有提交的话）：svn dump http://your-svn-repo -r 667:HEAD --incremental > post-666-dump.dump
• 新建一个干净的SVN仓库，先导入前半段历史：svn load http://new-svn-repo < pre-666-dump.dump
• 最后导入后半段增量：svn load http://new-svn-repo < post-666-dump.dump
  这种方式能精准跳过r666，同时保留所有其他历史，比维护两个仓库手动rebase/cherry-pick要可控得多，也不容易出错。

3. 反向合并后重新提交（针对逻辑错误类异常） #

如果r666只是提交逻辑错了（比如误改了不该动的文件、提交了错误的版本），反向合并是最优雅的处理方式：

• 切换到本地工作副本，执行svn merge -c -666 .撤销r666的所有变更
• 检查本地文件确认修正正确后，提交：svn commit -m "Revert r666 due to [具体异常原因，比如：提交了损坏的二进制文件]"
• 之后再重新提交正确的内容就行，整个过程历史完整，所有人都能看懂来龙去脉

为啥这些方法比临时方案好？ #

这些方案都不用放弃历史，也不用维护多个仓库，完全符合SVN的规范工作流：

• 保留完整的变更轨迹，后续排查问题更方便
• 操作可追溯，团队协作时不会产生混淆
• 避免多仓库同步带来的额外风险

内容的提问来源于stack exchange，提问作者DSUK