Question

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

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

或者是否有更好的方法可以使用Subversion的分支来获得更好的结果。

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

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

Answer 1

如果您的错误位于错误跟踪器中（它们应该是），您可以使用它来跟踪此错误。您的错误跟踪器应该有一些方法来标记受影响的版本。

为了确保实际解决已关闭的错误，QA /测试人员应在所有受支持的版本中测试错误实际已修复。

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

是由于主干上无关的更改而修复的错误，这个没有补丁需要吗？

由于其他变化，分支机构的补丁无法在主干上运行吗？

分支机构的补丁根本不适用于主干，而主干上需要不同的补丁吗？

测试确实是确保错误消失的最佳方法。如果您没有QA /测试人员，您可以让不同的开发人员这样做或雇用软件测试人员。

Answer 2

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

最后，我猜，这一切都归结为那些在分支上修复的人也负责将其合并到主干中。确保这种情况发生的最好方法可能是同伴压力。 :)

Answer 3

你可能想要调整Subversion开发人员自己使用的策略：在trunk中进行大部分开发，从分支中释放。当发现错误时，它首先在trunk中修复，然后修复程序从trunk合并到分支。

Answer 4

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

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

一种方法是质量保证，测试和错误跟踪器 - 随着代码更改，对代码执行某些操作的事实将通过各个阶段进行记录和跟踪。您通常不希望任何人在没有某些原因的情况下对代码进行更改（除了“我觉得它需要重构”之外），因此无论如何，跟踪工具都是个好主意。由于错误在一个版本中得到修复，因此该工具可用于确保错误在其他版本中得到修复（适当时 - 有时您不希望对版本进行特定更改）

SVN可以与这些工具集成，例如，我的仓库更新我的Mantis bugtracker，当一些魔术词被添加到签到时（如果你在签到评论中输入“fixed mantis＃1234”，mantis bug 1234将更新为已更改的文件及其状态已更改为“等待测试”）

此外，诸如评论板之类的工具也可以集成 - 当您进行更改时，可以在那里发布修订以供其他人注销，注销过程可以包括确保合并错误，或者为此创建新的错误报告您需要修复的其他版本。

所以 - 问题不在于SVN，而在于你的开发过程。

Answer 5

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

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

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 manual。

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

Answer 6

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

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

Answer 7

以下是我们正在做的事情，我只是blogged about it - 我们在CI服务器中设置了一个特殊的构建版本，确保在每晚的基础上不存在未合并的更改。

Answer 8

我实际上写了一段时间来做一个脚本。我们正在进行的项目中有许多同时进行的分支，并且很难跟踪所有提交和合并。

您可以在http://github.com/ccampbell/show-missing-revs

找到该脚本

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

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

这需要颠覆1.5我相信。希望你觉得这很有用！

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

8 个答案: