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

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

是否有方法监控合并以确保合并完成

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

更新：人们指出解决方案应该包括一个bug跟踪系统。我们确实使用Jira并用Jira问题ID标记每个提交。目前没有实现进一步的集成

---

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

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

---

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

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

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

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

svn公司https://server/repo/trunk
光盘中继
svn合并--重新整合https://server/repo/branches/branch_name
svn提交

有关更多详细信息，请参阅

---

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

首先，确保完成这些工作的方法是在版本分支上记录修复的签入，并在bug跟踪系统中的bug条目中记录合并到主干的签入。如果你没有bug跟踪系统，那就买一个吧。除了帮助跟踪修复外，它还解决了跟踪bug状态的许多其他问题

---

第二，你可能想考虑另一种方法。当你在发布的版本中复制一个bug时，试着在主干的头部也复制它。大多数时候你会发现它仍然在发生。把它固定在后备箱里，然后检查一下。然后将更改合并回需要修复的已发布版本的分支中（您可能需要修改修复以适应不同的环境）。如果bug只发生在发布分支中，那么它会在那里修复它（不需要合并到主干中）。

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

为了确保一个关闭的bug得到了实际解决，QA/测试人员应该测试该bug是否在所有支持的版本中都得到了修复

SVN的合并跟踪可以帮助一些人，但最终它不能告诉你：

• 这个bug是由trunk上的一个不相关的更改修复的，并且不需要这个补丁吗
• 分支的补丁是否由于其他更改而无法在主干上运行
• 分支的补丁根本不适用于主干，主干上需要另一个补丁吗

---

测试确实是确保bug消失的最好方法。如果你没有QA/测试人员，你可以让另一个开发人员来做，或者雇佣软件测试人员。

SVN中没有告诉你应该或不应该签入、分支、合并或删除哪些代码。那不是它的工作。它的工作做得非常好——它为您提供了一个版本化的工具来存储代码

因此，您不需要工具来更好地管理代码，您需要外部系统来更好地管理开发人员：）

一种方法是QA、测试和bug跟踪器——随着代码的更改，对代码做了一些事情的事实会在各个阶段被记录和跟踪。您通常不希望任何人在没有任何原因的情况下（除了“我觉得它需要重构”）对代码进行更改，所以不管怎样，跟踪工具都是一个好主意。由于bug在一个版本中已修复，因此此工具可用于确保bug在其他版本中也已修复（在适当的情况下-有时您不希望对某个版本进行特定更改）

SVN可以与这些工具集成，例如，当签入中添加了一些神奇的单词时，my repo会更新我的螳螂bugtracker（如果您在签入注释中键入“fixed Mantis#1234”，螳螂bug 1234将使用更改的文件进行更新，其状态更改为“等待测试”）

或者，reviewboard之类的工具也可以集成—当您进行更改时，可以将修订发布到那里供其他人签署，签署过程可以包括确保合并错误，或者为您也需要修复的其他版本创建新的错误报告

---

因此-这里的问题不在于SVN，而在于您的开发过程。

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

这就是我们正在做的，我只是-我们在我们的CI服务器中设置了一个特殊的构建，以确保每晚都不存在未合并的更改。

不久前，我实际上编写了一个脚本来实现这一点。我们同时有很多

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