在 SVN 中不起作用的 git 的具体示例合并答案

【问题标题】：Concrete sample merges of git that won't work in SVN在 SVN 中不起作用的 git 的具体示例合并
【发布时间】：2013-01-31 02:45:22
【问题描述】：

我正在寻找可以在 git 中工作但会导致 SVN 冲突的具体示例合并。除此之外，您从未尝试过的硬/痛苦 SVN 合并示例Git 也可以。

我可以识别出与我的问题相关的主要四类合并：

big bang merges
重命名/移动相关合并
在两个分支中创建了目录/相同的文件
criss cross merges

我错过了这里的任何场景吗？

查找 1-3 的样本是微不足道的（在 cmets 中查找 2 的样本，3 作为我答案的一部分，1 几乎是任何变基）。 有没有人提供样本（不看学术）成功的交叉合并，在 SVN 中会失败？

【问题讨论】：

stackoverflow.com/questions/2471606/… 会帮助还是作为一个好的起点？
@VonC 我想我已经在这里阅读了这个主题的“所有”问题；）我完全了解 git 和 SVN 背后的理论。但我正在寻找一个具体的样本。我不敢相信我是第一个必须以这种方式说服他的同事的人。肯定有人已经创建了这样的样本。样本应该是这样的：do x, do y, do z -> Conflict in SVN/Fine in git。关于 DAG 和树的长篇大论对于“电梯间距”来说毫无意义：)
您在该主题上没有找到很多内容的原因可能是，就其本身而言，SVN 和 Git 之间的“合并导致冲突”的区别并不是那么引人注目。您正在寻找切换到 Git 的真正原因的 0.01%。
@RyanStewart 每个人都听说过在 git 中合并比在 SVN 中更容易，我想这就是为什么每个人都希望看到这样的示例。就个人而言，历史/分支的可视化足以让我迁移到 Git :) 但它本身的所有小好处似乎都不足以证明迁移的合理性。说服管理层您需要的不仅仅是许多小而好的功能。在您看来，杀手级功能是什么？
@mnhg 杀手级功能？ rebase：即：让我们将我的开发应用到我的开发之上。这就是 git 的开始：作为 Linus 的补丁管理器，他每天都会应用他收到的数百个补丁。高效合并是其自然结果。仅仅为了合并而迁移是没有意义的：你迁移是因为可以灵活地通过变基和合并来集成其他人的代码：stackoverflow.com/a/804178/6309（加上离线提交、二等分等的所有其他优点）来源：（2009 ) gitster.livejournal.com/35628.html

标签： git svn merge

【解决方案1】：

octopus 合并策略当然值得一提？

通常很难找到章鱼合并最多 8 个分支（最少 3 个）的具体示例。

但是，为了更准确地回答您的问题，我认为提供一个人为的“这在 Git 中有效，但在 SVN 中无效”示例不会为您赢得与同事/管理层的任何战斗。

我认为在搬家后从 SVN 过渡到 Git 的经历中，我认为在不充分了解这两种工具的基本“基本要素”的情况下欣赏 Git 的真正力量是很困难的。我不确定 Linus 本人是否可以向不了解 Git 与 SVN 内部运作的人（典型的街上的人）展示一个成功的“电梯推销”。

有些人可能不同意这种观点，但我对 Git 的采用来自一些受人尊敬的人，他们说它是源代码控制的最佳工具；我信任他们，并且随着我从 Git 内部如何工作以及从其高效的工作流程中了解更多信息，他们已被证明是正确的。

我对使用 SVN 的持久记忆是每天解决合并冲突。我曾经认为这是开发软件的正常部分，但实际上并非如此。

【讨论】：

我认识的大多数 SVN 用户不惜一切代价阻止分支。告诉他们您可以一次合并多个不冲突的分支是没有用的:) 他们很高兴。作为我最后的论点之一，我只需要另一个他们可能也会遇到的好样本。（当然，我跳过了我的问题中的所有其他论点，但请不要假设我只是想把这个例子扔到他们的桌子上，然后不说别的就说服他们。）
章鱼合并是 git 特有的，而不是 SVN 的弱点
没有它就是弱点，所以我不同意。

【解决方案2】：

找到了一个article 有一个很好的样本。创建“team b”分支只是为了显示与在两个分支中创建相同目录的树冲突。这是一个概述：

【讨论】：

请不要参考“猴子手榴弹”示例：Subversion 具有代表性的一组真正弱点，无需证明完全退化案例
@LazyBadger 随意添加一些作为单独的答案！（顺便说一句。那里有很多猴子:)）
我刚想到：携带 SVN 手榴弹的猴子会死，但携带 git 手榴弹的猴子会活下来。这意味着样本似乎并没有那么糟糕......

【解决方案3】：

好吧，real sample of strange and bad merge 在现实世界中被捕获并注册

在分支中添加了文件
通过两次合并（分支 -> 主干 -> 另一个分支）文件出现在另一个分支中
在分支目标中编辑的文件
将分支合并到主干后因相关文件出现“树冲突”而失败

r9 | Badger | 2013-03-06 11:42:34 +0600 (Ср, 06 мар 2013) | 1 line Changed paths: M /branches/B2/src/add.txt

B2 changes in add.txt
------------------------------------------------------------------------
r8 | Badger | 2013-03-06 11:35:45 +0600 (Ср, 06 мар 2013) | 2 lines
Changed paths:
   M /branches/B2
   M /branches/B2/core.txt
   A /branches/B2/src/add.txt (from /trunk/src/add.txt:7)

Merge from trunk to B2
------------------------------------------------------------------------
r6 | Badger | 2013-03-06 11:31:36 +0600 (Ср, 06 мар 2013) | 1 line
Changed paths:
   M /trunk
   M /trunk/core.txt
   A /trunk/src/add.txt (from /branches/B1/src/add.txt:5)

Merge from B1 to trunk
------------------------------------------------------------------------
r5 | Badger | 2013-03-06 11:28:58 +0600 (Ср, 06 мар 2013) | 1 line
Changed paths:
   M /branches/B1/core.txt
   A /branches/B1/src/add.txt

B1 changes
------------------------------------------------------------------------

尝试从 b2 合并到主干（预期结果 - 将 src/add.txt 的更改合并到现有文件的主干版本中）

>svn merge --dry-run file:///Z:/Repo/branches/B2
--- Merging r4 through r9 into '.':
   C src\add.txt
 G   .
Summary of conflicts:
  Tree conflicts: 1

【讨论】：

我可能会遗漏一些东西，但这种情况不是重新整合合并的目的吗（在主干->分支合并之后）？
@maxim1000 - 1. 我不这么认为 2. 即使在 1.7 中也无济于事，其中 --reintegrate 不是分支中的最后一个操作