从外部仓库合并

本文已获得原始位置 http://blogs.collab.net/subversion/do-not-post-mer 的许可，并在此镜像。已删除或更新了失效的链接。

作者：C. Michael Pilato

发布 2008-03-29

对于许多人来说，即将发布的 Subversion 1.5 版本被宣传为类似于“合并跟踪和其他一些东西”。这可能是真的，因为投入到新的合并跟踪功能中的工作量超过了对其他各个领域的投资。但当然，Subversion 1.5 不仅仅是关于合并跟踪。在这个版本中还有其他几个主要功能。正如您所期望的那样，Subversion 社区在过去一年半的时间里也进行了无数的错误修复。但今天我想简要谈谈一个可能在你雷达之下溜走的半错误修复、半功能：从外部仓库合并。

Subversion 一直以来都允许你（某种程度上）执行跨仓库合并操作，即合并源位于一个仓库，而目标工作副本（你进行合并操作的目标）来自另一个（“外部”）仓库。毕竟，由于 Subversion 将合并视为本质上是应用差异，你可能会认为这些差异的来源并不重要。但这是一个鲜为人知的特性：Subversion 的 [公开 API](/docs/api/latest) 没有提及它；[Subversion 手册](https://svnbook.subversion.org.cn/) 没有提及它；Subversion 的发行说明也没有吹嘘它。事实上，我唯一知道这个特性存在的原因是，我在修改 Subversion 的合并跟踪功能时偶然发现了代码注释。为什么如此隐秘？这可能是那些意外的功能之一——那些并非有意设计为可工作，但实际上却可以工作的功能。或者，也许原因是它只在某些情况下有效。无论如何，来自外部仓库的合并实际上是一个隐藏的功能。

显然，受到“这应该可以工作”精神的鼓舞，一位 openCollabNet 社区成员发现了这个功能，同时也发现了它的不足。用户“argeman”在合并跟踪测试版程序论坛上发布了以下内容：

我已经测试了 svn 1.5 alpha2 一段时间（转换了一些仓库并进行了测试）。到目前为止，它运行得非常好。唯一仍然无法正常工作的是（它在之前的 Subversion 版本中也从未正常工作过）：如果我尝试从另一个仓库合并更改，那么添加的文件将无法正常工作。

我之前从未真正使用过来自外部仓库的合并，但立即认识到该功能的价值。我可以将其概括为两个词：“供应商分支”。供应商分支是维护对他人代码的私有定制的一种常见方法，无需逐个更改地镜像该代码。有不同的方法可以实现这一点。例如，你可以使用单独的分支，这些分支是给定供应商发布包内容的纯镜像，然后使用另一个分支，该分支包含当前使用的供应商包版本以及你的私有修改。你可以通过将纯供应商版本之间的差异应用于你的定制副本，来升级你的定制包。或者，你可以在版本控制分支中只保留供应商包的定制副本，并使用在未版本化的供应商包内容之间生成的差异作为补丁来升级该分支。还有一些受虐狂者完全避免使用版本控制的力量，只是维护需要在供应商包的每个新版本发布时更新的自定义补丁文件。（如果你属于这些人，有些人可以帮助你解决你的疾病。）

因此，从外部 Subversion 仓库合并的能力提供了一种类似于我之前提到的第一种和第二种方法的混合方法。在这种方法中，你只需要维护供应商包的单个定制副本，而无需跟踪供应商发布的纯镜像（因为纯版本可以从供应商的 Subversion 仓库中轻松获得）。但现在你可以使用版本控制工具将这些纯版本之间的差异合并到你的定制副本中，而不是处理混乱的补丁文件。

不幸的是，“argeman”并没有发帖说：“嘿，我刚发现了这个功能，它运行得很好！” 这篇文章是为了告诉我们这个功能有潜力，但它无法处理由于合并而需要添加的文件。然而，这就是参与开源软件开发的乐趣所在。我花了 40 分钟的时间修改了 Subversion 的代码来修复问题并编写回归测试，之后又花了一些时间进行相关的后续修复。因此，当 Subversion 1.5 发布时，我希望从外部仓库的合并将得到与仓库内合并相同的基本级别支持。合并源中的重命名仍然会导致与 Subversion 中一直存在的问题相同的复杂情况，并且合并跟踪逻辑将在从外部仓库合并时被绕过，但合并应该在最常见的情况下成功完成。