【发布时间】：2014-10-21 09:34:04
【问题描述】：
我最近开始在使用 SVN 1.5.5 作为存储库的环境中处理遗留代码库。这里的开发团队在 SVN 分支的机制上遇到了足够多的困难，以至于它已经被放弃了。我想在适当的时候保持分支的做法，并且遇到了一些我以前使用 SVN 从未经历过的困难。
在将trunk合并到一个分支时，我们发现有几十个没有改变的文件被列为已修改，而且它们往往会发生严重的冲突。 SVN 将冲突显示为与自身混合的文件的一部分。由于没有人实际编辑过这些文件，因此很容易选择正确的版本并继续前进，但这仍然让开发人员对这个过程感到不安全。然后，当将分支合并回主干时，没有人编辑的同一组文件将发生冲突。除了在一个或两个分支或主干中合法编辑文件时，svn 合并算法因创建其他烦人的冲突而臭名昭著。
我们通常在as is done in this guide 中分支和合并。但是，开发团队中有 12-15 人会直接与存储库交互，我不能保证每个人都 100% 地遵循“最佳实践”。在过去 8 年多的时间里，该项目还有许多其他开发人员。
我们还在 svn mergeinfo 上看到很多没有人编辑过的文件的冲突。每次发生这种情况时，它都是一组完全不同的文件，但它保证在涉及分支的任何时候都会发生。自分支创建以来的时间越长，产生的神秘冲突就越多。
有时使用“--dry-run”选项可以预测这些有冲突但未编辑的文件。有时，使用“--dry-run”不会显示任何意外冲突，但运行相同的合并命令最终会导致大约 45 个没有更改的文件发生冲突。
如果我在主干的根目录运行 'svn propget svn:mergeinfo'，我会得到一个很大的分支名称列表和它们所涵盖的修订号，例如：
/branches/5###_active_feature:27629-27780
/branches/7###_auto_friend_feature:43686-43693
/branches/7###_mobile_navigation:45430-45690
/branches/8###_tracking:44442-44719
/branches/9###_video_module:45388-45418
/branches/9###_episode_guide:45233-45287
...
/branches/11###_redesign:28289-28395,46973-48171
这样的行总共 54 行。这是 propget mergeinfo 的预期输出 - 只是一个分支列表？
我认为有些东西已经坏了，这不是以看似默认的方式进行分支/合并的预期结果。从 2007-08 年开始，我使用 SVN 一年多，从未遇到过如此严重的问题。但是，我不太确定从哪里开始寻找解决方案。我和一些同事考虑了以下几点：
我们的 svn 版本 (1.5.5) 有问题。我们需要升级，这可能需要与一些官僚作斗争，但不应该太痛苦。
在存储库历史记录中的某个时间点，svn mergeinfo 已损坏，或以某种方式手动编辑。有没有办法检查这个？如果有，有办法解决吗？
在存储库历史的某个时刻，它以某种方式“损坏”了。不知道如何在这里继续。
有没有其他人遇到过类似的问题？如何解决此问题，以使未修改的文件不会列为冲突，并且我的团队可以继续使用分支，而不必担心破坏代码库中的随机内容？
（记录在案，有一个长期项目要切换到git。不幸的是，暂时被SVN卡住了。）
【问题讨论】：
-
借助 DVCS，您仍然可以在一段时间内使用 SVN 跨越网桥（git-svn 或 hgsubversion）
标签： svn conflict branching-and-merging corrupt mergeinfo