处理 SVN 分支重复合并的正确方法是什么？答案

【问题标题】：What is the correct way to handle repeated merges of an SVN branch?处理 SVN 分支重复合并的正确方法是什么？
【发布时间】：2009-10-23 08:09:06
【问题描述】：

这里我们有一个 SVN 存储库，其中包含一个主干和一个用于新版本开发的分支。

分支即将发布，所以我决定将分支重新集成回主干。显然有一些冲突。包括大量树干中已删除的文件的树冲突。

我很高兴地解决了所有的冲突并提交了主干。

问题是我们随后对分支进行了一些小的更改，所以我再次重新集成了分支，并且发生了所有相同的树冲突。解决它们不是问题，但是有很多问题，并且需要一些时间来手动检查和解决它们，而且我不希望每次进行更改和重新集成时都必须经历相同的解决过程。我曾期望 SVN 能够识别分支已经重新集成一次，并且仅从上次重新集成发生的点合并。

当我打开修订图时，它显示了主干和分支被拆分的点，但它不显示合并。应该吗？

服务器：WinServer2003 (R2sp2)、VisualSVNServer (1.7.2)。客户端：WindowsXP(sp3)，我一直使用 TortoiseSVN (1.6.5) 来完成这一切，但我也安装了命令行客户端。

我通过确保主干是最新的并使用 TortoiseSVN 进行合并来进行合并，并在出现选项对话框时选择“重新集成分支”。我将合并深度设置为“工作副本”

我是否错误地处理了这种情况？我应该做些不同的事情吗？

（也许我们的存储库布局错误。我们从主干分支，对分支中的新版本进行了所有更改，现在发布到期了，我们正在将分支合并回主干。也许这是错误的方法，我读过一些人反其道而行之，在主干中进行所有更改，并仅在您几乎准备好发布并且分支成为受支持的发布版本时才创建分支）

【问题讨论】：

标签： svn tortoisesvn merge branch

【解决方案1】：

以下内容来自SVN书this chapter的结尾：

在 Subversion 1.5 中，一旦从分支到主干的 --reintegrate 合并完成，该分支就不再可用于进一步的工作。它无法正确吸收新的主干更改，也无法再次正确重新集成到主干。因此，如果您想继续处理您的功能分支，我们建议您将其销毁，然后从主干重新创建它

【讨论】：

宾果游戏。这正是我一直在寻找的——确认我的假设是无效的。我知道它会在那本大坝书中，它只是找到相关的部分。谢谢。

【解决方案2】：

在这种情况下，我不会在您完成开发之前将代码从分支合并到主干。

我会从主干合并到分支，以确保您的分支是最新的，并且对主干应用了任何修复。定期执行此活动以确保您的开发分支包含所有修复。然后在开发变为实时发布时，将分支合并到主干作为一次性活动。

我的回答做了一些假设，包括：

你有 live trunk 和 dev 分店
你只有一个活版本（即不维护旧版版本）

希望对您有所帮助。

【讨论】：

【解决方案3】：

现在实际上可以进行重复的双向合并

请注意。这个答案解释了它是如何完成的，但如果你错过任何一步，你会很抱歉。例如， --reintegrate 合并必须是完全无关紧要的（所有差异都已在分支中解决），否则当您继续在分支中工作时，您将默默地错过在 --reintegrate 合并步骤中所做的更改。另一种方法是在每次 --reintegrate 之后删除并重新创建分支。

至少在 svn 1.6 及更高版本中，您可以进行重复的双向合并。您可以使用 svn merge 多次从“主”分支合并到子分支，但是每次将分支合并回主分支时，都必须提供选项

--reintegrate 如其他答案所述。

您还需要做的是告诉您的分支您已将其集成在第二个手动步骤中（该分支已签出并更新），使用命令

svn merge --record-only -c 391 ^/calc/trunk

这里的 391 表示您刚刚在 calc/trunk 中所做的 --reintegrate 分支提交的合并提交号。

如果您错过了它，它可能仍然有效，或者您可能需要在下次合并时重新解决已解决的合并冲突。在仅记录步骤之后，您的分支已准备好进行进一步的工作或合并。这很愚蠢（特别是如果你像我一样被Git 宠坏了，事情就这样好了），但是如果你按照这个习惯去做，它就可以工作，而且两个分支总是对新的提交开放。

整个事情都记录在reintegrate twice下的SVN书中

此合并使用了樱桃采摘合并语法，该语法已被引入在名为“樱桃采摘”的部分中。继续跑步来自名为“重新集成分支”部分的示例，其中修订版 X 是修订版 391：

$ cd my-calc-branch $ svn update Updating '.': Updated to revision
393. $ svn merge --record-only -c 391 ^/calc/trunk
--- Recording mergeinfo for merge of r391 into '.':  U   . $ svn commit -m "Block revision 391 from being merged into my-calc-branch."
 Sending        .

 Committed revision 394.

现在您的分支已准备好再次从主干吸收更改。在将分支再次同步到主干后，您甚至可以再次重新集成分支。如有必要，您可以进行另一个仅记录合并以保持分支处于活动状态。冲洗并重复。

【讨论】：