问题标签 [three-way-merge]

我一直在使用 TortoiseSVN、svn 和 subclipse，并且我认为我了解基础知识，但是有一件事一直困扰着我一段时间：合并引入了不需要的代码。这是步骤。

trunk/test.txt@r2. 使用“A”创建了一个测试文件并返回：

branches/TRY-XX-Foo/test.txt@r3. 扩展trunk到TRY-XX-Foo：

branches/TRY-XX-Foo/test.txt@r4. 进行了不必要的更改TRY-XX-Foo并提交了它：

branches/TRY-XX-Foo/test.txt@r5. 修复了一个重要的错误TRY-XX-Foo并提交了它：

现在，我只想将重要的错误修复合并回主干。所以，我运行 merge for revision 4:5。我最终在我的工作目录中是一个冲突。

trunk/test.txt：

违背我的意愿，Subversion 现在已经在主干代码中包含了“不需要的更改”，我需要手动清除它们。当在分支中进行多次连续更改时，有没有办法只合并指定的修订？

问题的一部分是 B （未更改的更改）包含在 .merge-right 中，我无法区分它来自哪个修订版。我通常使用 TortoiseMerge，它的外观如下。

我目前使用 RCS 的合并命令进行 3 路合并，但有一件事一直让我烦恼。如果我使用 -A 选项，在两个文件中所做的相同更改会显示为冲突：

<<<<<<< file1
file1 line 1
||||||| orig
orig line 1
=======
file2 line 1
>>>>>>> file2
orig line 2
<<<<<<< orig
=======
在两个更改中添加的行
>>>>> >> file2
原始第 3 行

如果我使用默认值 (-E)，则不会显示这些相同的更改，但输出仅显示两个贡献者，而不是祖先，如下所示：

<<<<<<< file1
file1 line 1
=======
file2 line 1
>>>>>>> file2
orig line 2
line added in both changes
orig line 3

是否有一些程序基本上会执行与 RCS 合并相同的行为，但有某种方式可以显示所有三个冲突版本，同时自动合并相同的更改？

我看到这篇文章解释了如何让 BC3 作为 Subversion 的差异工具工作......但是使用 Beyond Compare 3 进行 3 路合并/比较呢？

有谁知道 JavaScript 或 PHP 中的开源三向合并实现？我想合并纯文本文件而不需要依赖任何服务器端二进制文件。

我找到了一些创建差异的解决方案，但没有合并实现。

UltraCompare Pro刚问世以来，我一直是它的用户，我认为它是一个功能非常齐全的比较和合并工具。但是，由于我一直在更仔细地研究 DVCS，我发现它处理三向合并的方式与（大多数？）其他工具不同。所以我想知道为什么会这样，以及我是否因此而错过了什么。

在 UltraCompare 中，有三个合并面板（我们称它们为 base、local 和 other）。所有合并操作都发生在这些面板中。在实践中，这意味着我在中间窗格（本地）上完成我的工作，合并来自右侧（其他）或可能来自左侧（基础）的共同祖先的更改。中间窗格在会话期间被修改，然后被保存 - 并作为合并的结果提交。第四个窗格（输出窗口）仅包含有关差异结果的信息。

_{（来源：ultraedit.com）}

在其他工具中，这三个窗格似乎仅以只读状态存在，而第四个底部窗格（输出）是所有合并发生的地方。有一个额外的合并窗口的原因是什么？跟踪所有更改是否更容易？还是只是因为每个人一直都这样做，所以我们正在复制这种行为？您对此有何看法？

_{（来源：hginit.com）}

我不确定是否存在最佳或正确答案，所以我还没有提出这个问题，但我也会在这里听从你的意见。

我有一个包含数千个文件的目录和 2 个适用于同一目录的补丁文件。每个补丁文件修补 dir 或其子目录中的 20-30 个文件。

如果我将任一补丁应用于共同的祖先目录，它就会成功。

但是如果我应用一个补丁文件然后另一个，它会失败，因为在应用一个补丁文件后行号已经改变。（两个补丁文件都存储来自共同祖先的差异）。在某些地方也存在冲突，我想使用一些图形工具（如 meld）进行 3 路合并。

我的目标是从补丁文件中进行 3 路合并，然后将这个最终目录递归地与共同祖先进行比较，以创建一个补丁文件。

一种方法是创建 2 个共同祖先的副本，将不同的补丁应用于 2 个副本，然后使用 meld 进行合并。meld 会花费大量时间比较未更改的文件（dir 有数千个文件）。有没有更好的方法来做到这一点？

如果您输入确切的命令，我将不胜感激，因为我是 linux 新手。

情况如下：需要将上游代码库（从V1到V2）的更改合并到从V1派生/分支的第三代​​码库S1中，以产生新的代码库S2。

我们可以访问 V1 和 V2 之间的日志和修订版本控制，以及 V1、V2 和 S1 的源。但是，S1 没有提供版本控制存储库和历史记录：不可能将其视为分支和进化主干之间的合并，因为从 V1 到达 S 的中间更改不是单独知道的。

情况是我们因此正在执行增量 3 路合并以生成 S2，并更新在 S1 中派生的更改以在 V2 的基础上工作。（我们不断发展的 V2 自然受到版本控制）

我发现 WinMerge 可用于识别目录结构之间完全不同/丢失/添加的文件，而 p4merge 在文件级别是一个很好的 3 路合并工具。

您建议使用哪些工具和技术？值得注意的是，代码库的规模很大，V1 和 V2 之间的中间修订数量很大，V1 和 S 之间的更改规模也很大。

维基百科说 3 路合并比 2 路合并更不容易出错，而且通常不需要用户干预。为什么会这样？

一个 3 路合并成功而 2 路合并失败的示例会很有帮助。

我有一组二进制配置文件，每个文件有三个版本——一个原始版本，每个文件有两个不同修改的版本。我需要能够同时看到两个版本之间的差异以及原始版本之间的差异。

我需要的是二进制文件的三向差异工具。通过相当累人的谷歌搜索，我最终偶然发现了一个应用程序的屏幕截图，该应用程序完全符合我的需要——不幸的是，包含该图像的论坛帖子没有提及他们正在使用的应用程序：

http://www.xboxhacker.org/index.php?topic=15032.0

有人可以指出我提供三个二进制文件的二进制安全（十六进制）比较的（Windows）应用程序的方向吗？

我正在学习 Git，并且发现此站点上的教程非常有用。在该页面上，关于合并，它包括：

合并提交是 (F)，有父 (D) 和 (E)。因为 (B) 是 (D) 和 (E) 之间的共同祖先，所以 (F) 中的文件应该包含 (B) 和 (D) 之间的更改，即标题修复，并合并到 (E) 的文件中。

我不明白你为什么会担心共同的祖先B。为什么你不能把D和E合并成F？D 将从 B 派生，但可能包含您想要的差异。B 和 D 之间可能已经进行了多次提交，并进行了更改和删除。