我不明白 svn 合并。这是场景：
我们有一个包含我们代码的最新稳定副本的分支。我将把这个分支称为“分支”。还有一个主干分支，其中包含一些新添加的内容，但我们现在不想弄乱它。
我们有一个供应商分支，其中包含运行我们的应用程序的库的更新版本。我想将此供应商分支中的新更改与“分支”合并，以便我们获得库的更新，而无需我逐个文件检查并找出新的内容。 不用了，谢谢。
现在，我意识到这可能很简单，但我已经尝试了 很多 的东西，并阅读了 很多 的教程，但我仍然无法包装我的围绕什么，确切地说，我应该与什么合并。
为了记录，我使用的是 Tortoise。
编辑： 这是一个澄清，但我们的应用程序在根级别运行库。我不知道这是否重要。所以'the branch' 基本上和'vendor' 是一样的，只是我们的改动而已。
【问题讨论】：
标签： svn tortoisesvn merge vendor-branch
这样的事情应该为你做。 Subversion 非常了解标准 diff 和 diff3，但它并不总是与 3rd 方（图形）diff 实用程序配合得很好。
$ cd "the branch"
$ svn merge --diff3-cmd=diff3 svn+ssh://yourrepository/path/to/vendor_branch"
【讨论】：
Vendor branches 是一种技术，允许您针对外部代码库维护自己的补丁，同时保持吸收新版本的能力（“供应商下降”）。这涉及合并您自己的更改和供应商更改。我不建议您尝试第一次合并实验，因为它是一个高级且复杂的用例。
但是，听起来您根本没有修改第三方代码。因此升级到较新版本的第三方代码不应该涉及合并。
诀窍是将您自己的代码和第三方代码分开（它们是独立的项目）并将它们与svn:externals 结合在一起。示例存储库布局：
/externallib/1.0
/externallib/2.0
/project/trunk
/project/trunk/externallib
/project/trunk/externallib 文件夹实际上并不存在于存储库中，但由于主干文件夹上的 svn:externals 属性具有此值，因此出现在您的工作副本中：
^/externallib/1.0 externallib
将主干升级到外部库的 2.0 版本只需将 svn:externals 定义更改为：
^/externallib/2.0 externallib
请注意，您应该将 externallib 版本视为标签；如果您开始修改它们，您将影响 /project/trunk/externallib 的内容，而 /project/trunk 中没有任何显式提交，这是一件坏事。
【讨论】：