TortoiseSVN / Subversion-分支到主干的定期合并

Question

我们公司最近已使用TortoiseSVN作为客户将版本控制系统切换为SVN，以促进使用敏捷开发方法。 我们的SVN信息库在主干中有多个分支，每个sprint一个。 我们通常执行“使分支保持最新状态，然后重新整合分支”方法。 但是，有时分支中的更改需要移植到主干或其他分支中！ （如错误修复）。 我们有一个不断发展的bugfixes分支（如果可能，我想将其保留为一个分支，以便使主干可以保持“纯净”状态）。

如果我定期合并从分支到主干的一系列修订版本，然后在完成我们的一组错误修正后重新集成分支到主干，这可以工作吗？ 我不想双重合并。 最好不要再进行重新整合合并，而只保留修订范围呢？ 我们正在使用SVN 1.6。

Answer 1

如果我定期合并从分支到主干的一系列修订，然后在完成我们的一组错误修复后重新集成分支到主干，这可以工作吗？

是的，它将起作用。

我不想双重合并。

由于您使用的是Subversion 1.6，因此只要不篡改svn：mergeinfo属性 ，Subversion就会跟踪已合并的更改，仅合并那些尚未合并的更改。

最好不要再进行重新整合合并，而只保留修订范围呢？

您可以任一个。 但是我建议您进行重新集成合并，除非您将补丁程序或修补程序移动到中继或另一个分支中。

关于从一个分支到另一个分支合并时修补程序或修补程序的一个注意事项：请注意该修补程序或修补程序是否具有新对象（文件和/或目录）。 有时，这些可能会导致树冲突，在释放分支，移入主干并从主干更新另一个分支之后，合并或重新集成可能会很痛苦。 Subversion 1.6.x和相关客户端在合并过程中会处理此问题，而较旧的客户端则不会。

Answer 2

两个问题：

• 您是否在一个发布周期中运行多个不相关的Sprint？

• 在每个发行周期结束时，您是否将发行标记为最新发行的生产版本？

如果您对第一个问题的回答是“是”，则对于多个分支以及从分支到主干的定期合并都是有意义的。 如果您定期标记发行版或每个发行版，则可能根本多余以完全运行分支并将主干作为“出血边缘”开发版本，包括错误修复。 YMMV。