Teo*_*Teo 1 svn merge branch mergeinfo svn-merge-reintegrate
我有一个从主干开始的分支A和从A开始的分支B.定期地,从主干到A的合并,然后也执行从A到B的合并.当我想将A和B合并到主干时,我想按照这种方式:
这是对的吗？或者它可能导致mergeinfo或其他问题的问题？在这种情况下,最佳做法是什么？
颠覆(有时是不公平的)因不良合并而受到批评.事实上,Subversion非常擅长合并.要了解您需要做什么,您需要了解Subversion如何合并.
通常颠覆,我将在稍后解释(标准的3向合并).它将合并的两个文件与这两个文件共享的最后一个祖先进行比较.这样,它可以告诉文件中的哪些更改来自它所在的分支,以及来自另一个分支的更改.
因为分支"B"来自来自树干的分支"A".你可以从trunk到B或trunk到A合并.这些合并应该可以正常工作.如果要将一组特定的更改从分支B或分支A合并到主干或另一个分支,那么一切都应该正常工作.
现在,我说(有点)做标准的3向合并.编写Subversion是为了允许您指定在一个分支中进行的特定更改集以与另一个分支进行合并.合并时,Subversion不查看您正在合并的文件,它从基础开始,最后一个共同的祖先,然后应用正在考虑进行合并的那些更改.在这种情况下,当您准确指定要合并的内容时,Subversion可以很好地进行合并.
因此,如果您指定分支"A"具有特定更改并且您希望将此更改合并到分支"B"或主干,则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:mergeinfo101到107的所有主干修订已经合并到我的分支中.因此,Subversion为我选择修订版112和113:
Subversion创建了修订版114,并设置svn:mergeinfo为从版本101到修订版113的主干上的所有更改都已合并到我的分支上.
现在,我已经完成了我的功能,并且我希望将我在分支上所做的所有更改合并到我的主干上.如果我不是一个懒惰的流浪汉,我会指定我要将修订版103,105,108,110和111合并到我的主干上.如果我这样做,那绝对没问题.Subversion在合并方面做得很好.
注意我没有指定我想要更改109和114合并(两个更改以粗体显示).为什么？因为那些不是我的分支上的变化,它们是我合并到我的分支上的主干变化.如果我指定了这两个版本,我会将我的主干更改重新应用到我的主干上.
但是,我很懒,我希望Subversion为我做这项工作.Subversion查看我的分支,并查看所有这些更改,包括更改109和114,并希望将这些更改合并到我的主干上.不好.
所以,Subversion在这里做了一些特别的事情.如果我们将文件和修订版本视为应用于文件的更改集,我基本上将我的主干上发生的所有更改应用到我的分支上,并将我分支上的所有更改应用到我的主干上.换句话说,当我完成这个分支到主干合并时,我的分支和我的主干将匹配.
这就是重新整合合并的作用.与普通合并不同,我将两个文件的更改与基本修订版进行比较,然后仔细应用,我的分支上的所有更改都将应用于我的主干,而不将其与基本修订版进行比较.在重返社会的合并是一个双向的合并.分支和主干之间的任何差异都将被覆盖.
让我们来看看会发生什么:
中继线: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上做更多的工作只是为了告诉你如果我继续使用我的功能分支会发生什么.我会在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和主干进行合并而不会出现任何问题.