我最近开始使用SVN 1.5.5作为存储库的环境中的遗留代码库。这里的开发团队在SVN分支机制方面遇到了很多困难，而这些分支已经被抛弃了。我喜欢在适当的时候保持分支的做法，并且遇到了以前从未使用过SVN的一些困难。SVN 1.5分支合并，大量未修改文件修改和/或冲突
当将树干合并到一个分支中时，我们发现许多未更改的数十个文件被列为已修改，并且它们往往会发生冲突。 SVN将conficts显示为与自身混合的文件的一部分。由于没有人真正编辑过这些文件，因此很容易选择正确的版本，然后继续前进，但这仍然使开发人员对流程感到不安全。然后，在将分支合并回主干时，没有人编辑的同一组文件将会发生冲突。这是除了其他恼人的冲突，svn合并算法臭名昭着创建文件时合理编辑一个或两个分支或树干。
我们通常分支并合并回as is done in this guide。然而，开发团队中有12-15人会直接与存储库交互，我不能保证每个人都在100％的时间内遵循“最佳实践”。在过去的8年以上，这个项目上还有许多其他开发人员。
我们在svn mergeinfo上也看到很多关于没有人编辑过的文件的冲突。每次发生这种情况时，它都会有一组完全不同的文件，但它保证随时都会发生分支。分支创建后的时间越长，结果就会产生越多的神秘冲突。
有时这些很多冲突但未编辑的文件可以用“--dry-run”选项预测。有时候，使用“--dry-run”不会显示任何意外的冲突，但是然后运行相同的合并命令最终冲突了大约45个没有变化的文件。
如果我运行“svn propget子的svn：合并信息”在我的树干的根部，我得到branchnames和它们覆盖的版本号，比如大名单：
/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） – 2014-08-27 23:20:55