Subversion分支合并的实用指南

Dón*_*nal 8 svn diff tortoisesvn merge branch

前言

我意识到在Stack Overflow上合并SVN分支已经存在很多问题.我已经阅读了很多这些,但仍然没有真正找到我正在寻找的信息,所以请在完整地将其作为副本关闭之前完整地阅读这个问题.


我需要将一个SVN分支合并到另一个分支.我对分支和合并的理论非常满意,但我总是在执行合并的过程中遇到困难,更具体地说,就是识别和解决冲突.我怀疑这个问题的根本原因是缺乏对完成工作所需工具的理解,即TortoiseSVN和各种可用的可视化合并工具.

基于阅读各种相关的Stack Overflow问题,我将Sourcegear DiffMergeBeyond Compare确定为执行三向合并的候选工具.我尝试过DiffMerge,但很难有效地使用它.我希望在解决冲突时看到以下三个文件

  • 来自分支A的文件
  • 分支B的文件
  • 执行合并的结果

但相反,我所看到的是

  • 来自分支A的文件
  • 分支B的文件
  • A和B的共同祖先,AKA基础修订

这让我想知道在视觉上解决冲突后我采取的每个动作后如何看到合并的结果.我也努力实际执行这样的操作,例如,接受来自分支A或B的特定更改.在阅读了更多的主题后,现在看来基本修订实际上是合并结果的地方应该显示,这是正确的吗?

我认为使用TortoiseSVN和视觉合并工具演示合并分支的截屏视频或视频教程可能会回答我关于如何有效使用这些工具的大部分突出问题.我对解决执行合并本身的冲突的过程更感兴趣,但如果两者都被覆盖,那将会很棒.

Jir*_*uda 5

实际上,有双向和三向合并工具.一个双向应该显示三个窗口.源分支版本A,目标分支版本B和合并的结果.除此之外,三向合并还将显示基本版本.你可以想象一个三向合并类型为Result = Target +(Base - Source)的等式.实际上,该算法将计算基础和源之间的差异集以及基础和目标之间的另一组,然后删除两者共有的所有差异.然后它会显示剩余差异的列表以供决策.对于源或目标中的差异,其中相同的代码段在另一个分支中不受影响,它将自动预先决定使用适当的差异.如果差异在两个分支中位于相同的代码段中,则差异被标记为冲突,您的工具通常会逐个引导您完成冲突.冲突不是预先确定的,在您做出决定之前,代码不会出现在结果文件中.您可以选择跳到下一个差异或下一个冲突.所有冲突必须由您决定.根据您的知识,有时您想要回滚(重新决定)甚至非冲突的差异以完成合并.

因此,合并文件的过程基本上是通过差异向下移动,或者仅通过相互冲突的差异来加速,并决定是否采用源分支更改,目标分支更改或编辑相关代码以创建新的合并更改.您所做的更改应显示在结果窗口中,一旦您确定所有冲突,该工具应该允许您保存结果,然后该结果将成为目标分支上的新版本.具有基本文件的窗口通常仅作为没有源或目标更改的版本的参考显示.

一些工具允许所谓的自动合并.如果没有冲突的差异,该工具将使用预先确定的差异分辨率,而不会向您提出任何问题.从而自动从源和目标分支中获取所有更改.虽然词汇上这些变化不会发生冲突,但它们可能仍会以其他方式发生冲突.生成的代码可能无法编译或逻辑正确.但没有合并工具可以决定.这就是为什么合并结果应该由人阅读和审查,然后在提交到目标分支之前编译并运行测试套件的原因.


Gra*_*rdx 1

Perforce有一个合并工具,它会向您显示所有四个版本(基础、A、B 和合并),并会直观地向您显示合并的外观。

在进行复杂的合并时,我实际上发现仅查看原始文件(假设它不是字节数据)并自己比较修订片段很有帮助。如果您的合并非常复杂(即重叠合并、移动代码等),这很可能是唯一的方法。

我见过的另一件事是导出工作集的一个副本,然后使用并排工具(如Beyond Compare)手动合并,然后直接签入。

关于合并总是让我困惑的一件事是它们与我预期发生的情况背道而驰。这总是给我带来基础修订版的问题。