4

我一直在努力了解 SVN 合并/重新集成，并阅读了这些文章/书籍：

http://svnbook.red-bean.com/en/1.5/index.html
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

我显然还没有完全明白，因为我不明白为什么在合并回主干（反射/循环合并）中包含同步修订是一个问题 - 我确实看到了不排除修订的理由。

如果trunk上的一行文件A被合并到branch上的文件A'中，然后又合并回trunk，那么A和A'肯定没有区别，所以不冲突？为什么“[合并]主干中已经存在的更改”是一个问题？

我正在尝试复制冲突场景，以尝试了解 reintegrate 为我做的事情，但更让我困惑的是这种情况：

  1. 在主干上提交更改 (r4)
  2. 将 r4 合并到分支并提交 (r5)
  3. 在分支上提交更改 (r6)
  4. 通过以下任一方式将分支合并到主干：
    • 将修订范围 r5-r6 合并到主干 - 发生冲突，或
    • 将 r5 合并到主干，然后将 r6 合并到主干 - 不会发生冲突

我正在使用 SmartSVN 6.6 和 SVN 1.6。为什么与单独合并每个修订版相比，合并修订版范围时会产生不同的结果？最终，为什么包含反射合并是一个问题？

4

1 回答 1

5

基于我对颠覆合并行为的观察（不是书籍/源知识）的简短回答：

  1. 具有显式修订的合并似乎完全不知道早期的合并，并且会像您进行合并一样频繁地重新应用更改。

  2. 没有任何修订范围的“常规”合并知道哪些修订已经合并（到目标分支）。通常不会应用两次更改。但是，它不会检查要合并的更改是否源自现在是合并目标的同一分支。发生这种情况时，它会进行某种上下文敏感的合并，但冲突会更频繁地出现。

  3. merge --reintegrate 能够检测到源自合并目标过去的更改，并且不会重新应用这些更改。不幸的是，重新集成仅适用于功能分支。

我尽量避免任何类型 1. 的合并。2.“常规”类型的合并只能通过合并到一个方向来驯服。当您再次上下合并时，麻烦就开始了。每当我需要像在功能分支场景中那样“交叉合并”时，我都会使用合并类型 3。

SVN 根本无法“盲目地”支持广泛的合并操作:)。没有 VCS 可以解决所有相互冲突的人类决策。

为什么svn合并冲突

其特殊的“冲突性”的部分原因可以在颠覆历史中找到。在 SVN 1.5 之前，只有显式合并。您必须知道您已经合并了哪些修订范围，并基于该知识进行下一次合并，否则您描述的冲突将会发生。

pre 1.5 SVN 中的合并看起来像：

（分支的 HEAD 版本为 510） svn merge -r500:510 http://server.tld/branches/stable-1.0

下一个合并将是：

（分支的 HEAD 版本为 520） svn merge -r510:520 http://server.tld/branches/stable-1.0

此语法仍然有效且有效。

您可以阅读我在 svn 1.4 最佳实践中描述的内容：（注意，遗留链接！）http://svnbook.red-bean.com/en/1.4/svn.branchmerge.copychanges.html#svn.branchmerge.copychanges .bestprac.track

随着 SVN 1.5 中引入的合并功能，它开始衡量您的一些意图。例如，现在 SVN 将计算定义范围以自动合并并跟踪合并的内容。更少的开销，更少的人为错误导致的冲突。但是当使用许多分支时，您仍然可能需要两次应用更改。Subversion 保留了这种能力。

如何与之共存

您在 4 步示例中所做的樱桃采摘使您的树干和树枝保持“紧密”。在步骤 3 中，您的两个分支是相同的，因此在步骤 4 中合并不再有意义。我知道你简化了，在现实世界的场景中会有更多的变化。但是颠覆分支的主要思想是分离。从不稳定、不兼容的开发、自定义构建中保持稳定...

樱桃挑选/交叉合并的需要通常只是对分支和分支使用策略考虑得不够充分的一个症状。

如果分支交叉交易经常变化，也许你可以把它们变成一个。

我将停止讲课;-) 在这一点上，希望我没有让你太困惑。

如果您想了解更多关于 svn 最佳实践的信息，您可能会在我的 SO-Answers 或 SVN 红皮书中找到一些内容。如果这对您来说是个问题，我可以向您发布有关正确采摘的图表。

干杯

于 2010-10-27T14:08:10.190 回答