合并svn分支之间的变化

Question

背景

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

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

这一切都很好。

问题

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

从BranchA合并到BranchB的正确方法是什么，以便在BranchA合并回主干后，在从trunk到BranchB的下一个MRoR上没有出现树冲突？

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

感谢您的帮助！

Answer 1

我已经完成了一些测试，并且已经弄明白了。我将继续分享如何做到这一点，以防更多的人有同样的问题 回顾一下：

• BranchA和BranchB存在（从主干分支）。
• BranchA添加/重命名/移动/删除等文件
• BranchB已将BranchA合并为自身（通过合并修订范围（MRoR））。
• BranchA拥有来自主干的MRoR（因此它是最新的并且可以合并）。
• BranchA已合并（使用合并两棵树（MTDT））回到主干。
• 如果BranchB尝试从trunk获取更改（使用MRoR），则会出现树冲突。

当你想到它时，树冲突实际上是有意义的。从BranchB的角度来看，它从BranchA获得了一些从合并中修改过的文件，然后再从中继的合并中获得了一些文件。因此，树冲突。问题是来自主干的合并不允许BranchB知道BranchA已合并到主干。 实际上有两种方法可以解决这个问题。

解决方案：

方法1（更复杂的方法）

1. 在BranchA已经MTDT进入主干之后，从主干到分支A执行MRoR。 BranchA现在包含trunk的分支历史，后分支A MTDT。
2. 从BranchA到分支B执行MRoR。 BranchB现在包含BranchA MTDT之后的主干历史记录。
3. 从主干到分支B的MRoR。没有树冲突！耶！

方法2（更简单的方法）

1. 在BranchA合并后的任何时候，从 BranchA（@ revision最后合并到BranchB）到主干（@任何修订后的分支A MTDT）执行MTDT - HEAD会很好地进入BranchB。
2. 从主干到分支B的MRoR。没有树冲突！耶！

为什么方法2更好的原因（除了它减少1步之外）。

• 方法1在合并分支（每次）后需要一个额外的步骤（步骤1），这使分支合并过程变得复杂。
• 同样，方法1要求步骤1在深思熟虑中完成，跳过该步骤意味着方法2是唯一的救赎（为什么不首先使用方法2？）。
• 如果已删除BranchA，则使用方法1，您必须找到A存在的最后一个修订版（执行步骤2）。这可能是一种痛苦。
• 从方法2中的步骤1中找到对MTDT的正确修订非常简单。只需查看BranchB的历史记录，它的最新修订版BranchA就是MRoR＆＃39; d in。
• 如果在BranchA中最后一个MRoR与BranchB之间进行了新的更改，并且当BranchA被MTDT转入主干时，方法2将考虑到这一点，并仍然将所有必要的内容合并到BranchB中。

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

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

Answer 2

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

   • 弱点：对于SVN 1.8。*具有相当好的智能合并跟踪步骤3，必须（任何时间）才能完成＆＃39;完成＆＃39;合并（见svn help merge表格.1）
   • 大错误：将功能分支合并到主干/子级到父级/绝不可能（从来没有）双URL合并（我甚至无法想象你是怎么做到的）：而不是万亿字，我建议重读＆＃34;重新整合合并示例＆＃34;来自一次又一次的帮助

2. AFAICR，即使正确的工作流程为＆＃34;循环＆＃34;不久前合并（A-> B-> C-> A）神秘的树冲突（在TSVN 1.8.11之前和之中）（您的体验现在可能不同）并在Mercurial中合并分支（包括手工）通过Mercurial的工作目录的内容替换SVN目标的WC - Mercurial可以双向地与SVN交互，但是stll不能将自己的合并集推入SVN-repo）和手动编辑SVN中的mergeinfo