有时当我从主干合并项目时,即使我的版本和主干之间没有区别,一些文件也会出现修改(即,需要通过合并签入)。比较表明它们完全相同,即使空白没有不同。
- 这怎么可能?它与 mergeinfo 有关吗?
- 考虑到没有更改,不将这些文件签入我的分支有什么副作用...
- 当我尝试合并回主干时会不会有麻烦?
您可能会看到的其中一件事是报告在合并期间文件已更新,即使它没有更新。这可能是由于更新了svn:mergeinfo
该文件或目录的属性。
通常,只有项目的根目录应该有一个svn:mergeinfo
属性,因为您几乎应该总是从项目的根目录合并。但是,一些开发人员习惯于合并单个文件和目录,因为他们知道这些已被更改。svn:mergeinfo
当开发人员这样做时,Subversion 开始使用他们自己的属性跟踪这些文件和目录的合并。
现在,当您进行合并时,svn:mergeinfo
即使文件本身没有更改,所有这些属性也必须更新。毕竟,Subversion 仍然必须跟踪您是否进行了特定的合并,即使它不影响该文件,以便能够跟踪已合并和尚未合并的内容。
如果svn:mergeinfo
是问题,请不要还原文件。否则,Subversion 只会一遍又一遍地重做无用的合并。您可以尝试svn:mergeinfo
从该特定文件的主干和分支中删除 ,但请注意不要忘记合并的内容。
在 Subversion 中合并并不像应有的那样干净利落。Subversion 识别两种不同类型的合并:
需要重新集成概念,因为您的分支包含您从主干合并到分支的内容,并且在该分支上工作,而不是主干本身。您不希望合并到分支中的内容再次放置在主干中,因此重新集成功能仅将分支上的工作复制回主干(实际上是双向合并)。完成此操作后,您必须非常小心地再次合并回该分支。
为什么?:该分支上的所有更改都已合并到主干中,从而创建了新的主干修订。如果您执行一个新的 Subversion 主干到分支合并,Subversion 将看到由合并创建的新修订,并尝试将新修订包含的所有更改重新合并回分支。
要处理此问题,请使用--record-only
合并选项将主干中的新修订合并回分支。现在,当您从主干合并回分支时,将不会考虑合并该新修订:
$ svn co $REPO/trunk
$ cd trunk
$ svn merge --reintegrate $REPO/branch/1.2 #Two-way Reintegrating branch 1.2 to trunk
$ svn commit -m"Reintegrate 1.2"
commit revision 12345
合并创建了修订版 12345。这必须只记录回分支,以便我们能够重用分支:
$ svn co $REPO/branch/1.2
$ cd 1.2
$ svn merge -c 12345 --record-only $REPO/trunk
$ svn commit -m"Mark Reintegrate Merge as completed"
- 这怎么可能?它与mergeinfo有关吗?
是的,它确实。您也许可以svn:mergeinfo
从主干和分支中删除该文件中的信息。但是,您需要小心。或者,您现在可以忽略它,因为您知道它没关系。
- 考虑到没有更改,不将这些文件签入我的分支有什么副作用...
Subversion 将在下次合并时再次尝试合并,每次合并花费的时间越来越长,因为每次必须合并更多的修订。
- 当我尝试合并回主干时会不会有麻烦?
当您从分支合并到主干时,您必须使用该--reintegrate
参数来防止分支将更改重新合并回主干。重新整合合并仅使用双向合并。这基本上使主干与分支匹配。
完成此操作后,您必须小心从主干到分支的新合并。
大卫在与“Merge-Hell”有关的麻烦的大多数(不是全部)方面都是正确的。但我想对一些具体细节做一些补充说明
svn diff
修改的工作副本中将显示WC 中的所有svn diff
更改,两个节点之间(合并集和合并源)也将显示所有这些细节 - 试试看