1

我最近开始在使用 SVN 1.5.5 作为存储库的环境中处理遗留代码库。这里的开发团队在 SVN 分支的机制上遇到了足够多的困难，以至于它已经被放弃了。我想在适当的时候保持分支的做法，并且遇到了一些我以前使用 SVN 从未经历过的困难。

在将trunk合并到一个分支时，我们发现有几十个没有改变的文件被列为已修改，而且它们往往会发生严重的冲突。SVN 将冲突显示为与自身混合的文件的一部分。由于没有人真正编辑过这些文件，因此很容易选择正确的版本并继续前进，但这仍然让开发人员对这个过程感到不安全。然后，当将分支合并回主干时，没有人编辑的同一组文件将发生冲突。除了在一个或两个分支或主干中合法编辑文件时，svn 合并算法因创建其他烦人的冲突而臭名昭著。

我们通常按照本指南中的做法进行分支和合并。但是，开发团队中有 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 卡住了。）

4

1 回答 1

2
  1. 很多分支源/trunk都可以 - 他们只是在一段时间内合并了很多分支
  2. AFAICR，合并跟踪和合并信息的概念仅在 1.6+ 中引入，以前的合并实际上是“合并地狱”
  3. 我认为，无论如何您都必须验证|修复存储库，也许 - 分为“存档代码库”和“活动代码库”。
  4. 更新到 SVN 1.8（在双方，但至少在客户端上）将是不错的选择：您将获得更轻松的合并（在需要的步骤中）
于 2014-08-27T19:24:27.363 回答