问题：
这里：
b1 = svn branch 1
b2 = svn branch 2
我无法理解：
如果我将branch b1 与branch b2 合并
如果我通过使用 meld 或 Beyond compare 之类的工具区分 b1 and b2 创建一个补丁，然后将该补丁应用到 b2
这完全一样/相似吗？
如果是，那为什么我可以离线使用step 2 [没有互联网] 而step 1 只能使用svn merge 在线完成？
请解释！！
【问题讨论】：
标签： svn version-control merge diff patch
下面是一个例子，展示了 diffing 和 merging 之间的根本区别（我们甚至没有谈论 SVN）：
假设您在 b1 和 b2 中都有一个文件 F。 F 在 b1 中有一个额外的行，但在 b2 中没有。根据您是diff b1/F b2/F 还是diff b2/F b1/F，Diffing 会给您不同的结果。在一种情况下，它会告诉您该行已被删除，在另一种情况下 - 它已被添加。那么你要应用哪个补丁呢？
合并（即使是常规的 no-svn 合并）是相对于第三个源完成的——通常是共同的祖先。然后您通常可以判断该行是添加还是删除 - 如果它在祖先中则被删除，如果不是 - 添加。
换句话说，合并是应用 b1 和 b2 的更改。简单的差异无法知道发生了什么变化 - 没有第三来源。
现在，如果你也有共同的来源 - 你可以实现类似于 svn merge 的结果。你甚至可以争辩说，有时 SVN 是一个真正的害虫，因为当完全相同的更改应用于两个分支时，你会尖叫你有冲突。理论上，当离线合并不会给您正确的结果时，可以提供示例，它们主要适用于不识别冲突。此外，SVN 还对合并进行了一些有用的簿记。
因此，如果绝对必要，您可以这样做：保留公共源 b 的副本；当您需要将 b1 合并到 b2 中时：diff b1 b 并将补丁应用于 b2。
更好的是（正如我之前提到的）使用 Git 或 Mercurial。
【讨论】：
GIT - 但我的公司使用svn。反正这不重要。如果相同的文件在 svn 上而不是在补丁上引起冲突 - 所以，这是 svn 的副作用，而不是有用的东西。无论如何..所以step 1和step 2的输出，会有什么区别吗？ svn 知道合并吗？我的意思是 svn 是否知道发生了合并，或者更改只是已提交的更改？
svn merge，而不是“外部”合并。
svn merge，因为某些版本（1.5？）在一个特殊属性svn:mergeinfo中记录了合并的URL和修订范围，它允许Subversion跟踪已经合并的内容，因此促进所谓的“重新集成”——当在一个分支上完成的开发定期合并到另一个分支时，因为 Subversion 能够通过查看 svn:mergeinfo 来了解“合并基础”。