我已经对子目录合并错误的原因做了一些研究，并且最近发现了我们的存储库中有一个包含mergeinfo的子目录。
我正在尝试手动删除此合并信息，并希望查看我是否正确理解mergeinfo并正确执行。
ROOTDIR mergeinfo
/支链/ Iteration53：18065-18126
/支链/ Iteration54：18150-18204,18210-18231
/ branches / Iteration55：18341,18348,18353-18355,18357,18364-18365＆lt; =====此行不同
/支链/ gdsRework：17329-17457
/树干：17869,18085
SUBDIR mergeinfo
/支链/ Iteration53 /猕猴桃幅：18065-18126
/支链/ Iteration54 /猕猴桃幅：18150-18204,18210-18231
/ branches / Iteration55 / kiwi-web：18336-18428＆lt; =====此行不同
/支链/ gdsRework /猕猴桃幅：17329-17457
/中继/猕猴桃幅：17869,18085
两者之间只有一条线不同。我还注意到SUBDIR mergeinfo中的范围18336-18428包含ROOTDIR mergeinfo中同一行的所有修订。
所以我的计划是用SUBDIR中的行替换ROOTDIR中的那一行并一起删除SUBDIR mergeinfo：
新ROOTDIR merginfo
/支链/ Iteration53：18065-18126
/支链/ Iteration54：18150-18204,18210-18231
/ branches / Iteration55：18336-18428＆lt; =====现在与SUBDIR mergeinfo相同
/支链/ gdsRework：17329-17457
/树干：17869,18085
删除SUBDIR mergeinfo。
这样安全吗？陷阱会在哪里？提前谢谢。
答案 0 :(得分：3)
不建议手动编辑mergeinfo。虽然在过去我做了类似你描述的事情，即使root和subdir之间的差异更加复杂，这种编辑也非常容易出错，因此需要非常小心和准确。正如我后来所了解到的，SVN足够强大，可以很容易地解决这种情况;所以最好不要养成手动合并信息编辑的习惯。
简单的情况是SUBDIR mergeinfo中记录的“额外”修订仅影响该子目录。在这种情况下，您只需要在ROOTDIR级别进行仅限记录的修订18336到18428的合并。仅记录合并将更新ROOTDIR的mergeinfo而不触及任何文件，并且，由于SUBDIR mergeinfo将与ROOTDIR完全相同，因此它将删除过多。
--record-only选项添加到您用于实际合并的svn merge命令中。请注意mergeinfo中的范围（包括其两端和中间的所有内容）与-r选项中的范围之间的区别（指定两个修订以获取diff）;例如在命令行中，您需要指定-r 18335:18428，即获取差异的起始修订版比第一个要合并的版本少一个。
更复杂的情况是，如果这些修订合并到SUBDIR中，但ROOTDIR也不会更改SUBDIR之外的文件。这些变化很可能尚未合并。如果忽略这些更改是安全的，那么您也可以进行仅记录合并。相反，如果碰巧错过了这些更改，您可能会想要对ROOTDIR级别的修订进行定期合并，并修复合并冲突（如果有）。
合并完成后（仅记录或常规），检查目录是否正确更改了mergeinfo，并提交结果。
一篇很好的文章，其中我学习了很多关于mergeinfo以及它如何被SVN命令操作（包括仅记录合并，mergeinfo elision等），这里是：Subversion 1.5 Mergeinfo - Understanding the Internals。我建议您在尝试修复存储库中的mergeinfo之前先阅读它。