合并 svn 分支之间的更改

Question

背景

我们的服务器正在运行 subversion 1.8.10。我们的客户使用 1.8+。我们主要使用 TortoiseSVN（所以我将使用乌龟术语来描述），版本 1.8+。
我们（常见的）颠覆工作流程是：

• 从主干分支/标记（并切换到它）。
• 随着时间的推移定期更新/提交工作。
• 根据需要合并从主干到分支的修订范围 (MRoR)。
• 比较主干和分支之间的 URL，以区分和进行代码审查。
• 合并两个不同的树 (MTDT)，从主干到分支，以便合并回主干。
• 分支清理。
• 继续（重复）。

这一切都很好。

问题

我们遇到过一些情况，例如，BranchA 发生了一些变化（例如，添加了一些文件）。它是最新的（来自主干）并在合并回主干之前经过代码审查。 BranchB 已创建（从主干），并希望从 BranchA 中获取更改，以便从中构建。
如果我们从 BranchA 到 BranchB 的 MRoR，我们会得到预期的更改。我们可以根据需要多次合并 BranchA，我们也可以从主干 MRoR 到 BranchA 或 BranchB .. 一切看起来都很好。
BranchA 可以合并回主干（使用 MTDT），工作正常。但是，一旦我们再次 MRoR 主干到 BranchB，在 BranchA 合并后，我们就会遇到树冲突。为什么是这样？ SVN 正在跟踪合并历史，它可以看到 BranchA 是谁创建/移动/等文件。如果我执行相同的过程，而是使用 MTDT 从 BranchA 合并到 BranchB，结果是完全相同的。即使 BranchB 没有自己的更改，这种情况仍然会发生。

从 BranchA 合并到 BranchB 的正确方法是什么，这样在 BranchA 合并回主干之后，在下一次从主干到 BranchB 的 MRoR 时不会出现树冲突？

这种事情在 git 中很容易完成。我确信应该有办法解决树冲突。

感谢您的帮助！

Answer 1

1. 在深入之前，您必须自己修复工作流程中的弱点和错误：

   • 弱点：对于 SVN 1.8.*，具有相当好的和智能的合并跟踪步骤 3 可以|必须（任何时间）只是“完整”合并（参见 svn help merge 表格。1）
   • 大错误：将功能分支合并到主干/子级到父级/不得（而且从来没有）两个 URL 合并（我什至无法想象你是如何做到的）：而不是无数我会建议您一遍又一遍地从帮助中重新阅读“重新集成合并示例”

2. AFAICR，即使使用正确的“循环”合并工作流程 (A->B->C->A) 神秘的树冲突（在 TSVN 1.8.11 之前和之前）（您现在的经验可能不同）并完成了 Mercurial 中的合并分支（其中包括通过 Mercurial 工作目录的内容替换 SVN 目标的 WC - Mercurial 可以与 SVN 双向交互，但不能将自己的合并集推送到 SVN-repo）和手册SVN中mergeinfo的编辑

Answer 2

我已经进行了一些测试并弄清楚了。我会继续分享如何做到这一点，以防更多人有同样的问题。
回顾一下：

• BranchA 和 BranchB 存在（从主干分支）。
• BranchA 有一些文件添加/重命名/移动/删除/等。
• BranchB 已将 BranchA 合并到自身中（通过 Merge Range of Revisions (MRoR)）。
• BranchA 已从主干进行 MRoR（因此它是最新的并且可以合并）。
• BranchA 已合并（使用合并两棵不同的树 (MTDT)）回到主干。
• 如果 BranchB 尝试从主干获取更改（使用 MRoR），则会出现树冲突。

当您考虑时，树冲突实际上是有道理的。从 BranchB 的角度来看，它从 BranchA 的合并中获取了一些修改过的文件，然后又从主干的合并中获取了一些文件。因此，树冲突。问题是来自主干的合并不会让 BranchB 知道 BranchA 已合并到主干中。 实际上有两种方法可以解决这个问题。

解决方案：

方法一（更复杂的方法）

1. 在 BranchA 被 MTDT'd 进入主干后，从主干到 BranchA 执行 MRoR。现在，BranchA 包含主干、BranchA 后 MTDT 的历史记录。
2. 执行从 BranchA 到 BranchB 的 MRoR。 BranchB 现在包含 BranchA MTDT 后的主干历史记录。
3. MRoR 从主干到 BranchB。没有树冲突！耶！

方法2（更简单的方法）

1. BranchA 合并后的任何时间，执行 MTDT from BranchA（@修订最后合并到 BranchB）to 主干（@任何修订后 BranchA MTDT -- HEAD 会很好）进入 BranchB。
2. MRoR 从主干到 BranchB。没有树冲突！耶！

方法 2 更好的更多原因（除了它少了 1 步）。

• 方法 1 在分支合并后（每次）都需要一个额外的步骤（步骤 1），使分支合并过程复杂化。
• 同样，方法 1 需要预先考虑步骤 1，跳过该步骤意味着方法 2 是唯一的救星（为什么不首先使用方法 2？）。
• 如果 BranchA 已被删除，使用方法 1，您必须找到 A 存在的最后一个修订版（执行步骤 2）。这可能会很痛苦。
• 从方法 2 的步骤 1 中找到正确的 MTDT 修订版非常容易。只需检查 BranchB 的历史记录，它的最新版本 BranchA 是 MRoR 的。
• 如果在上一次 MRoR 到 BranchB 之间的 BranchA 中进行了新的更改，并且当 BranchA 被 MTDT'd 到主干时，方法 2 将考虑到这一点，并且仍然将所有必要的内容合并到 BranchB 中。

如果不清楚，请使用方法2。
我知道这是一个高级的 SVN 工作流程。但是，我希望这个解释对遇到类似问题的其他人有所帮助。

TortoiseSVN 合并策略源码： https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html