我有一个分支A从主干开始，分支B从A开始。 定期地，从主干到A的合并，并且稍后还执行从A到B的合并。 当我想将A和B合并到主干时，我想按照这种方式：
这是对的吗？或者它可能导致mergeinfo或其他问题的问题？在这种情况下，最佳做法是什么？
答案 0 :(得分：7)
Subversion一直（有时不公平地）因合并不当而受到批评。事实上，Subversion非常擅长合并。要了解您需要做什么，您需要了解Subversion如何合并。
Subversion通常，（我稍后会解释）进行标准的3向合并。它将合并的两个文件与这两个文件共享的最后一个祖先进行比较。这样，它可以告诉文件中的哪些更改来自它所在的分支，以及来自另一个分支的更改。
因为分支＆＃34; B＆＃34;来自Branch＆＃34; A＆＃34;它来自树干。你可以从trunk到B或trunk到A合并。这些合并应该可以正常工作。如果要将一组特定的更改从分支B或分支A合并到主干或另一个分支，那么一切都应该可以正常工作。
现在，我说（有点）进行标准的3向合并。编写Subversion是为了允许您指定在一个分支中进行的特定更改集以与另一个分支进行合并。合并时，Subversion不查看您要合并的文件，它从基础，最后一个共同祖先开始，然后应用正在考虑进行合并的那些更改。在这种情况下，当您准确指定要合并的内容时，Subversion可以很好地进行合并。
因此，如果您指定分支＆＃34; A＆＃34;有一个特殊的变化，你想将这个变化合并到分支＆＃34; B＆＃34;或者对于主干，Subversion在合并方面做得很好。
当Subversion开始跟踪之前合并到分支或主干的存储库修订时，Subversion 1.5开始发生变化。这使我无法合并先前合并到分支中的更改，但它也让我变得懒惰。懒惰没有错。我高度赞同它。
想象一下，我从主干版本100修改了一个功能分支。我在修订版100中创建了分支。让我们说这是我的回购中的修订列表：
当我从主干到我的功能分支合并，并且我没有指定我要合并的修改时，Subversion会为我挑选。它知道最后一个共同的祖先是修订版100.它然后查看并看到修订版101,102,104,105,106和107的主干上的更改尚未应用于我的分支。然后，它选择这些特定的更改并将它们合并到我的分支。
修订版109是我合并的结果。为了跟踪这些变化，Subversion在修订版109中提出了svn:mergeinfo属性，该属性表示trunk：101-107已合并到分支上：让我们做更多工作：
我想再次从我的行李箱合并到我的分行。如果我不懒，我会指定我想将修订版112和113合并到我的分支上。但是，懒惰，我让Subversion完成工作。 Subversion从svn:mergeinfo看到从101到107的所有主干修订已经合并到我的分支中。因此，Subversion为我选择了修订版112和113：
Subversion创建了修订版114，并设置svn:mergeinfo表示从修订版101到修订版113的主干上的所有更改都已合并到我的分支上。
现在，我已经完成了我的功能，并且我希望将我在分支上所做的所有更改合并到我的主干上。如果我不是一个懒惰的流浪汉，我会指定我要将修订版103,105,108,110和111合并到我的主干上。如果我这样做，那根本就没问题。 Subversion在合并方面做得非常好。
注意我没有指定我想要更改109和114合并（两个更改以粗体显示）。为什么？因为我的分支上没有这些变化，所以我将它合并到我的分支上。如果我指定了这两个版本，我会将我的主干更改重新应用到我的主干上。
但是，我很懒，我希望Subversion为我做这项工作。 Subversion查看我的分支，并查看所有这些更改，包括更改109和114，并希望将这些更改合并到我的主干上。不好。
所以，Subversion在这里做了一些特别的事情。如果我们将文件和修订版本视为应用于文件的更改集，我基本上将我的主干上发生的所有更改应用到我的分支上，并将我分支上的所有更改应用到我的主干上。换句话说，当我完成这个分支到主干合并时，我的分支和我的主干将匹配。
这是重新整合合并的功能。与普通合并不同，我将两个文件的更改与基本修订版进行比较，然后仔细应用，我的分支上的所有更改都将应用于我的主干，而不将其与基本修订版进行比较。 reintegration merge 是双向合并。分支和主干之间的任何差异都将被覆盖。
让我们来看看会发生什么：
中继：101 102 104 105 106 107 112 113
svn:mergeinfo现在说trunk:101-113
中继：101 102 104 105 106 107 112 113 115
svn:mergeinfo现在说trunk:101-113
svn:mergeinfo现在说branch:103-114 让我们在trunk上做更多的工作只是为了告诉你如果我继续使用我的功能分支会发生什么。我还要对主干进行两次更改：
中继：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如何合并跟踪以及重新集成合并的内容，我们就可以了解您的情况：
如果你是一个勤奋的年轻程序员，每天早上5点醒来跑5英里只是为了让你有工作的心情，你将指定你想要合并到其他分支或主干的每个分支的修订。如果你这样做了，那就没有问题了，你做标准的合并，并为你在健身房锻炼身体后每天骑行100公里做好准备。
如果您是一名典型的技术工作者（即懒惰的）并且您希望Subversion为您选择修订版，那么事情会有所不同：
svn merge --record-only将分支B记录到分支A重新整合更改到分支B，并且分支A到分支重新集成更改到分支A。知道在Subversion中进行常规合并还是重新整合合并可能有点容易出错。这是一个手动过程，如果我作为一个正常的人，犯了一个错误（我将在最糟糕的时候做），这可能是一场灾难。
在Subversion 1.8中，Subversion现在尝试通过查看svn:mergeinfo哪种方式进行合并以及何时必须进行重新整合合并来确定。因此，您不再需要在合并时指定--reintegration标志。 Subversion还将确保在重新集成到另一个分支或主干后重新应用分支，而不是重新应用重新集成期间发生的更改。
如果你想做很多功能分支，你应该使用Subversion 1.8，它将为你处理很多合并跟踪中的错误倾向。如果您使用的是Subversion 1.8，您应该能够从分支B到分支A和主干进行合并而不会出现任何问题。