如何确保 Subversion 版本分支中的错误修复合并到主干中

Question

我们将我们的软件版本作为 Subversion 中的分支进行管理。最新发布的版本是 trunk。较旧的发布版本是一个分支（也按构建和发布进行标记）。当开发人员修复旧版本中的错误时，他有责任将修复合并到主干中。如果错过了这一步，则很难注意到，直到该错误可能在更高版本中再次出现。然后我们必须重新调试和修复它。

有没有办法监控合并以确保它们完成？

或者有没有更好的方法来使用 Subversion 的分支来获得更好的结果。

更新：人们指出解决方案应该包括错误跟踪系统。我们确实使用 Jira 并使用 Jira 问题 ID 标记每个提交。目前尚未实施进一步的整合。

解决方案可能是采用更好的流程。但如果有任何工具可以支持这个更好的过程，我想了解它们的存在，或者使用它们的方式。

Answer 1

如果您的错误在错误跟踪器中（它们应该是），您可以使用它来跟踪它。您的错误跟踪器中应该有某种方法来标记哪些版本受到影响。

为了确保已关闭的错误确实得到解决，质量检查/测试人员应该测试该错误在所有受支持的版本中实际上已修复。

SVN 的合并跟踪可以帮助一些人，但最终它无法告诉您：

• 该错误是否是通过主干上的不相关更改修复的，并且不需要补丁？
• 由于其他更改，来自分支的补丁是否无法在主干上工作？
• 分支的补丁是否根本不适用于主干，并且主干上需要不同的补丁？

测试确实是确保错误消失的最佳方法。如果您没有 QA/测试人员，您可以让其他开发人员来完成或雇用软件测试人员。

Answer 2

从版本 1.5 开始，SVN 将有关合并修订的信息放入属性中。您应该能够在那里找到它并理解它。但是，这仅告诉您合并了哪些修订版，而不是忘记合并哪些修订版。

最后，我想，这一切都归结为那些对分支进行修复的人也负责将其合并到主干中。确保这种情况发生的最好方法可能是同侪压力。 <代码>:)

Answer 3

您可能需要调整 Subversion 开发人员自己使用的策略：在主干中进行大部分开发，从分支中发布。当发现错误时，首先在主干中修复它，然后将修复从主干合并到分支。

Answer 4

SVN 中没有任何内容可以告诉您应该或不应该签入、分支、合并或删除哪些代码。那不是它的工作。它完美地完成了它的工作 - 为您提供了一个版本化工具来存储您的代码。

因此，您不需要一个工具来更好地管理您的代码，您需要一个外部系统来更好地管理您的开发人员:)

一种方法是 QA、测试和错误跟踪器 - 当代码发生更改时，对代码所做的操作会在各个阶段进行记录和跟踪。您通常不希望任何人无缘无故地对代码进行更改（除了“我觉得需要重构”），因此跟踪工具无论如何都是一个好主意。由于错误在一个版本中得到修复，因此该工具可用于确保该错误也在其他版本中得到修复（在适当的情况下 - 有时您不希望对某个版本进行特定更改）

SVN 可以与这些工具集成，例如例如，当一些魔术词添加到签入中时，我的存储库会更新我的 Mantis bugtracker（如果您在签入注释中键入“fixed mantis #1234”，mantis bug 1234 将使用更改的文件进行更新，并且其状态更改为“等待测试” ')

另外，评论板等工具也可以集成 - 当您进行更改时，可以将修订版本发布到那里供其他人签署，签署过程可以包括确保错误被​​合并，或者为其他人创建新的错误报告发布您也需要修复它。

因此，问题不在于 SVN，而在于您的开发流程。

Answer 5

首先，确保完成这些事情的方法是在错误跟踪系统中的错误条目中记录版本分支上修复的签入以及到主干的合并签入。如果您没有错误跟踪系统，请购买一个。除了帮助跟踪修复之外，它还解决了跟踪错误状态的许多其他问题。

其次，您可能需要考虑另一种方法。当您在已发布版本中复制错误时，请尝试将其也复制到主干的头部。大多数时候你会发现它仍然在发生。在主干中修复它并检查修复。然后将更改合并回需要修复的已发布版本的分支中（您可能需要修改修复以适应不同的环境）。如果错误只发生在发布分支中，那么它会在那里修复它（不需要合并到主干）。

Answer 6

较新版本的 subversion（我认为从 1.5 或 1.6 开始）具有合并跟踪。也就是说，颠覆会跟踪分支中的哪些更改已合并到主干。

您可以使用命令将所有更改从分支合并到主干：

svn co https://server/repo/trunk
cd trunk
svn merge --reintegrate https://server/repo/branches/branch_name
<check merge results, run unit tests, etc>
svn commit

请参阅 Subversion 手册了解更多详细信息。

这样，您将在分支中完成所有更改并到达主干。但是，如果您不想获取从分支到主干的所有更改，则必须使用 svn diff 来注意更改并选择要合并的更改。

Answer 7

这就是我们正在做的事情，我刚刚在博客上介绍了它 - 我们在我们的 CI 服务器中设置一个特殊的构建，以确保每晚不存在未合并的更改。

Answer 8

事实上，我不久前写了一个脚本来做到这一点。我正在从事的一个项目上有许多同步分支，并且很难跟踪所有提交和合并。

您可以在以下位置找到该脚本： http://github.com/ccampbell/show-missing-revs

假设您有一个 2.0 发布分支。要找出 2.0 中提交的尚未合并到主干的所有内容：

cd /path/to/trunk
sh /path/to/show_missing_revs.sh -b 2.0 -u username (optional) -v (verbose)

这将输出类似以下内容：

r2532 | username | fixing bug with this
r2631 | username | fixing bug with that

我相信这需要 subversion 1.5。希望您觉得这很有用！