前言
我意识到在Stack Overflow上合并SVN分支已经存在很多问题。我已经阅读了很多这些信息，但仍然没有真正找到我正在寻找的信息，所以请在完整之前将其完整地阅读这个问题。
我需要将一个SVN分支合并到另一个分支。我对分支和合并的理论非常满意，但我总是在执行合并的过程中遇到困难，更具体地说，就是识别和解决冲突。我怀疑这个问题的根本原因是缺乏对完成工作所需工具的理解，即TortoiseSVN和各种可用的视觉合并工具。
基于阅读各种相关的Stack Overflow问题，我已将Sourcegear DiffMerge和Beyond Compare确定为执行三向合并的候选工具。我尝试过DiffMerge，但很难有效地使用它。我期望在解决冲突时看到以下三个文件
但我所看到的是
这让我想知道在视觉上解决冲突后我采取的每一个动作后如何看到合并的结果。我也努力实际执行这样的操作，例如，接受来自分支A或B的特定更改。在阅读了更多的主题后，现在看来基本修订实际上是合并结果的地方应该显示，这是正确的吗？
我认为使用TortoiseSVN和视觉合并工具演示合并分支的截屏或视频教程可能会回答我关于如何有效使用这些工具的大部分优秀问题。我对解决执行合并本身的冲突的过程更感兴趣，但如果两者都被覆盖，那将会很棒。
答案 0 :(得分：5)
实际上，有双向和三向合并工具。一个双向应该显示三个窗口。源分支版本A，目标分支版本B和合并的结果。除此之外，三向合并还将显示基本版本。你可以想象一个三向合并类型为Result = Target +（Base - Source）的等式。实际上，该算法将计算基础和源之间的差异集以及基础和目标之间的另一组，然后删除两者共有的所有差异。然后它会显示剩余差异的列表以供决策。对于源或目标中的差异，其中相同的代码段在另一个分支中不受影响，它将自动预先决定使用适当的差异。如果差异在两个分支中位于相同的代码段中，则差异被标记为冲突，您的工具通常会逐个引导您完成冲突。冲突不是预先确定的，在您做出决定之前，代码不会出现在结果文件中。您可以选择跳到下一个差异或下一个冲突。所有冲突必须由您决定。根据您的知识，有时您想要回滚（重新决定）甚至非冲突的差异以完成合并。
因此，合并文件的过程基本上是通过差异向下或仅通过相互冲突的差异加速并决定是否进行源分支更改，目标分支更改或编辑相关代码以创建新文件合并后的变化。您所做的更改应显示在结果窗口中，一旦您确定所有冲突，该工具应该允许您保存结果，然后该结果将成为目标分支上的新版本。具有基本文件的窗口通常仅作为没有源或目标更改的版本的参考显示。
某些工具允许所谓的自动合并。如果没有冲突的差异，该工具将使用预先确定的差异分辨率，而不会向您提出任何问题。从而自动从源和目标分支中获取所有更改。虽然词汇上这些变化不会发生冲突，但它们可能仍会以其他方式发生冲突。生成的代码可能无法编译或逻辑正确。但没有合并工具可以决定。这就是为什么合并结果应该由人阅读和审查，然后在提交到目标分支之前编译并运行测试套件。
答案 1 :(得分：3)
您可以安装KDiff3以与TortoiseSVN执行三向合并。它在Windows平台上自动与TortoiseSVN集成。
它显示的三个文件是两个分支的共同祖先，来自分支A的文件和来自分支B的文件。然后将冲突解析为代表您要合并到的分支的文件。
我发现它是一个非常智能的工具，在正常情况下会自动选择正确的选项来合并简单的冲突。
如果不确定，它会问你该怎么做。
我偶尔会遇到选择错误方法的问题。那些分支/合并路径非常复杂的场合。
而且，正如GrayWizard所说，有时候查看原始文件会更容易。 Subversion将在您要合并的分支中使用标记生成单个原始文件，以显示哪些更改来自哪个修订。我有一两次需要在我的IDE中打开该文件并从那里修复它。
答案 2 :(得分：1)
Perforce有一个合并工具，可以显示所有四个版本（基础，A，B和合并），并会直观地显示你的合并会是什么样的。
在进行复杂的合并时，我实际上发现仅查看原始文件（假设它不是字节数据）并自己比较修订部分是有帮助的。如果您的合并非常复杂（即重叠合并，移动代码等），这可能是唯一的方法。
我看到的另一件事是导出工作集的一个副本，然后使用并排工具（如Beyond Compare）手动合并，然后直接签到。
总是让我想到合并的一件事是他们从我预期发生的事情中退缩了。这总是给我带来了基本修订版的问题。