从分支分支，重新整合合并和mergeinfo

Question

我有一个从主干开始的分支A和一个从A开始的分支B。定期进行从主干到A的合并，然后再执行从A到B的合并。 当我想将A和B合并到主干时，我想遵循这种方式：

• 从B重新合并到A
• 从A重新整合合并到主干

这是正确的吗？ 还是会引起合并信息问题或其他问题？ 在这种情况下，最佳做法是什么？

Answer 1

Subversion因合并不当而受到批评（有时是不公平的）。 实际上，Subversion确实擅长合并。 要了解您需要做什么，您需要了解Subversion如何合并。

通常，Subversion会执行标准的三向合并（稍后将进行解释）。 它将两个文件合并到共享的最后一个祖先。 这样，它可以判断文件中的哪些更改来自它所在的分支，以及哪些更改来自另一个分支。

因为分支“ B”来自于主干的分支“ A”。 您可以从主干到B或从主干到A合并。这些合并应该可以正常工作。 如果您要合并从分支B或分支A枯萎到主干或另一个分支的一组特定更改，那么一切都应该很好。

现在，我说（某种程度上）执行标准的3路合并 。 编写Subversion是为了允许您指定在一个分支中进行的特定更改集，以与另一个分支合并。 合并时，Subversion不会查看要合并的文件，它从基础（最后一个共同祖先）开始，然后应用为合并考虑的那些更改。 在这种情况下，当您确切指定要合并的内容时，Subversion会完成出色的合并工作。

因此，如果您指定分支“ A”具有特定更改，并且希望将此更改合并到分支“ B”或主干，则Subversion在合并方面做得很好。

当Subversion开始跟踪先前合并到分支或主干中的存储库修订时，Subversion 1.5中的情况开始发生变化。 这阻止了我合并以前合并到分支中的更改，但是这也使我变得懒惰。 懒惰没有错。 我高度赞同。

想象一下，我在主干的修订版100中创建了一个功能分支。 我在版本100处创建了分支。假设这是我的仓库中所做的修订的列表：

• 分行 ：103105108
• 行李箱 ：101102104105106107

当我从主干合并到功能分支时，并且没有指定要合并的修订版本，Subversion会为我完成任务。 它知道最后一个共同祖先是修订版100。然后，它看到并发现修订版101、102、104、105、106和107的主干上的更改尚未应用于我的分支。 然后樱桃选择这些特定的更改并将它们合并到我的分支中。

• 分行 ： 103105108109
• 行李箱 ：101102104105106107

修订版109是我合并的结果。 为了跟踪更改，Subversion在修订版109上添加了一个svn:mergeinfo属性，该属性表示trunk：101-107已合并到分支：上。 让我们做更多的工作：

• 分支 ：103 105 108 109 110 111
• 行李箱 ：101102104105106107112113

我想再次从树干合并到分支。 如果我不偷懒，我会指定我要将修订版112和113合并到我的分支中。 但是，由于懒惰，我让Subversion完成了工作。 Subversion从svn:mergeinfo看到，所有从101到107的主干版本都已经合并到我的分支中。 因此，Subversion为我选择了修订版112和113：

• 分支 ：103 105 108 109 110 111 114
• 行李箱 ：101102104105106107112113

然后Subversion创建了修订版114，并设置svn:mergeinfo表示从修订版101到修订版113的主干上的所有更改都已合并到我的分支中。

现在，我已经完成了功能，我想将在分支上所做的所有更改合并回我的主干。 如果我不是那么懒惰，我会指定我希望将修订版103、105、108、110和111合并到我的主干上。 如果我这样做了，那绝对没有问题。 Subversion在合并方面做得很好。

注意，我没有指定要合并的更改109和114（两个更改以粗体显示）。 为什么？ 因为这些不是我分支上的更改，所以它们是我合并到分支上的主干更改。 如果指定了这两个修订版，则将重新应用我的主干更改回我的主干。

但是，我很懒，并且我希望Subversion为我完成工作。 Subversion查看我的分支，并查看所有这些更改，包括更改109和114，并希望将其合并到我的主干中。 不好。

因此，Subversion在这里做了一些特别的事情。 如果我们认为文件和修订是要应用于文件的变更集，则基本上是将我在主干上进行的所有更改都应用到分支上，而将所有在分支上进行的更改都应用到我的树干上。 换句话说，当我完成此分支到主干合并时，我的分支和主干将匹配。

这就是重新整合合并的工作。 与正常的合并不同，常规合并将两个文件中的更改与基本修订进行比较，然后仔细应用，而分支上的所有更改都将应用于主干，而无需将其与基本修订进行比较。 重新整合合并是两种方式的合并。 分支与主干之间的任何差异都将被覆盖。

让我们看看会发生什么：

重新整合之前

• 分支 ：103 105 108 109 110 111 114

• 行李箱 ：101102104105106107112113

• svn:mergeinfo的分支现在显示trunk:101-113

重新融合后

• 分支 ：103 105 108 109 110 111 114

• 行李箱 ： 101102104105106107112113115

• svn:mergeinfo的分支现在显示trunk:101-113

• svn:mergeinfo在树干上现在显示branch:103-114

让我们在中继上做更多工作，只是向您展示如果我继续使用功能分支会发生什么。 我将在中继上再进行两个更改：

• 分支 ：103 105 108 109 110 111 114

• 外线 ：101 102 104 105 106 107 112 113 115 116 117

• svn:mergeinfo的分支现在显示trunk:101-113

• svn:mergeinfo在树干上现在显示branch:103-114

现在，我想将这些更改合并回我的功能分支。 如果我自己摘樱桃，我会指定我要对分支进行修订116和117，因为这是我刚刚进行的两个更改。 再说一次，如果我勤奋好学，那么Subversion合并就可以了。 但是，我很懒，将让Subversion进行摘樱桃。

Subversion查看svn:mergeinfo并看到我已将更改103更改为114到我的分支上。 现在，它在我的主干上看到三个新更改：更改115、116和117。但是，更改115是我重新整合合并的结果！ 115中的所有更改都已经在分支上。 让Subversion进行挑选将导致灾难。

这就是为什么告诉您在重新集成分支后不要重用它的原因。 解决此问题的方法是从主干到我的分支上执行svn merge --record-only -c 115 。 实际上不会进行任何合并，但是现在Subversion将记录101到115的更改在我的分支上。 如果我这样做了，然后从主干到分支进行了合并，则Subversion将跳过选择更改115，而仅执行更改116和117。

---

既然您了解了Subversion如何进行合并跟踪以及什么是重新整合合并，我们就可以看一下您的情况：

• 您从树干分支到分支A
• 您从分支A分支到分支B
• 您从中继合并到分支A
• 您从分支A合并到分支B

如果您是一个勤奋的年轻程序员，每天早晨5点醒来奔跑5英里，只是为了让您有工作的心情，则可以指定要合并到其他分支或主干的每个分支的修订版本。 如果您这样做了，那完全没有问题，您可以进行标准合并，并在健身房进行了充分的锻炼之后，准备好进行每天100公里的自行车骑行。

如果您是典型的技术人员（即懒惰的人），并且希望Subversion为您处理版本的选择，则情况会有些不同：

• 您将所有更改从分支A合并到分支B。现在，分支B将包括分支A上的所有修订。
• 你做分支B的重返合并到分公司A.现在所有对支路A和支路B您的修改将在两个分支。
• 您将主干与分支A进行常规合并。分支A包含您在分支A上所做的所有更改。此外，还包含分支B和主干上的所有更改。
• 您将分支A（已经包含您的分支B更改） 重新整合到主干上。 现在，主干，分支A和分支B都包含相同的更改集，并且所有三个更改都应匹配。
• 现在，除非您执行svn merge --record-only记录分支B到分支A的重新集成更改到分支B以及分支A到主干的重新集成更改到分支A上，否则您永远不要再使用分支A或分支B。

---

Subversion 1.8的重要更改

知道在Subversion中执行常规合并还是重新合并合并可能会出现一些错误。 这是一个手动过程，如果我作为一个普通的人犯了一个错误（在最糟糕的时候我会做的），这可能是一场灾难。

在Subversion 1.8中，Subversion现在尝试通过查看svn:mergeinfo来确定您进行合并的方式以及何时必须进行重新集成合并。 因此，您不再需要在合并时指定--reintegration标志。 Subversion还可以确保，如果在将分支重新集成到另一个分支或主干后重新使用它，则不要重新应用在重新集成过程中发生的更改。

如果您想进行很多功能分支，则应使用Subversion 1.8，它将为您处理合并跟踪中的许多错误倾向。 如果您使用的是Subversion 1.8，则应该能够将分支B合并到分支A并合并到中继中，而不会出现任何问题。