在 SVN 中应该如何进行合并答案

【问题标题】：How should merges be performed in SVN在 SVN 中应该如何进行合并
【发布时间】：2014-02-04 19:42:06
【问题描述】：

我有一个关于 SVN 合并过程的问题。

我在 branch1 中有一些文件修改，我想将这些更改合并到 branch2、branch3 和 trunk。

是否应该从 branch1 -> branch2 然后 branch2 -> branch3 最后 branch3 -> trunk 进行合并？

或

是否应该从 branch1 -> (branch2, branch3 和 trunk) 完成合并？

【问题讨论】：

要回答这个问题，您需要提供有关每个分支的祖先的信息。是所有的树枝都是从树干上剪下来的，还是有些是从其他树枝上剪下来的？
所有的树枝都是用树干做成的

标签： svn merge

【解决方案1】：

当您在 SVN（以及其他/可能不是全部/ SCM）中合并两个（任何）节点时，在最常见的情况下，目标将从中获得 所有更改来源，从历史分歧点开始

因此，如果您只想将来自 branch1 的更改填充到其他节点，您可以

对具有相同源的 N 个目标 - 分支 1 执行“完整”合并（读取 svn help merge，第一种形式）N 次（在检查历史记录时最符合逻辑和可读性）
执行“完整”合并到一个（任何）目标，使用 此合并集作为其他目标的“樱桃挑选”合并的源（它将起作用，将给出相同的结果，但似乎超逻辑解决方案）

PS - 与可变源的“完整”合并导致中间分支的所有更改将出现在目标分支中，即 for

然后是 branch2 -> branch3，最后是 branch3 -> trunk

branch3 将得到 branch1+branch2 的变化
trunk 将得到 branch1+branch2+branch3 的变化

而不是为其他开发分支共享来自 branch1 的更改

【讨论】：

你永远不应该在 Subversion 的兄弟分支之间执行合并，未来合并的基础选择可能会搞砸。所以你的第一个建议只是糟糕的建议。他需要将分支 1 合并回主干，然后从主干进行追赶合并（如果他也想要这些更改，则拉取并非来自分支 1 的更改）或将主干提取到分支 2 和分支 3。
@BenReser - “未来合并的基础选择可能会搞砸” WTF？！ 给我看看现实生活中的样本！！！WIP 导致树干中毒是BAD IDEA (tm)。恐怕，有了这样的开发者，Subversion 就自信地被丢进了历史的垃圾箱
那家伙说他无论如何都想将更改带回主干。所以谁说任何关于 WIP 变化的事情。我们实际上几乎不知道他的工作流程是什么样的，因为他没有告诉我们。我也不是说情况是理想的，只是告诉你它的方式。稍后我会在这里举一个例子。当我只是想指出事情的状态时，我也真的不欣赏这种侮辱。
Easy case 这完全符合您的预期：paste.apache.org/fQeu Hard case（branch1 拆分文件，幸好 branch2 和 3 没有接触，否则会有其他冲突，Java 开发人员重构很多时看到这种事情）paste.apache.org/60cM这失败了，因为我们计算了新文件的基本错误并尝试再次添加它。只有在主干和分支之间合并才能避免这种情况：paste.apache.org/5I9f 您也可以通过不使用 svn cp'ing 来避免这种情况，但这样会失去责任历史。是的，这很糟糕，是的，这是因为没有“真正的”分支。