对于很多人来说，Subversion1.5 被宣传为“合并跟踪还有其他”，也确实如此，花费在合并跟踪特性上的力量远大于其他领域，当然，Subversion 1.5不仅仅是合并跟踪这一项功能，也有一些其他的特性。Subversion社区为解决无数的bug话费了一年半的时间，但是现在我要讲的是一个半 bug，半特性，或许会被你忽略的一个功能：从远程版本库合并。
Subversion现在允许你 — 部分的，近似的 – 允许你将版本库合并到另一个版本库的工作拷贝，因为Subversion模型的合并就是区别（diff）的应用，你也许会希望不应考虑diff的源，但是这是一个没有人讨论的特性，Subversion的public API 没有提及此事，Subversion book也 没有涉及，Subversion的发布说明也没有吹嘘此时。实际上，我是在修改Subversion合并跟踪特性时注意到代码的注释，为何要隐藏这个秘 密？当然，也许这只是一个意外的特性 — 并没有刻意去实现，但是却完成了。亦或许原因是这个特性仅仅有时候有效，无论怎样，从另一个版本库合并实际上是一个隐藏特性。
显然，在“by golly this ought to work”精神的鼓舞下，一个openCollabNet 成员发现了这个特性，也发现了其缺陷，用户“argeman”在合并跟踪beta程序论坛发布了这些内容：
我测试了svn 1.5 aopha2（转化了一些版本库然后使用了一下），它工作良好，唯一还没有工作的事情是（它不能在以前的subversion版本上工作），如果我尝试从另一个版本库合并时，无法正常添加文件。
我确实没有从另一个版本库上进行合并，但我立刻认识到了这个特性的价值，我可以用两个词来总结：“卖主分支（Vendor branches）”，卖主分支通常用来在不断变化中保存其他人的代码中的自定义修改，有很多方法可以实现，例如，你可以使用独立的分支，是某个卖主发布 包的镜像，而另一个分支包含了你的软件中正在使用的包含你自定义修改的卖主包，你通过将纯卖主发布的区别应用到你的自定义拷贝实现升级。或者，你可以在你 的版本控制分支中只包括卖主包的自定义拷贝，使用diff生成未版本化卖主包数据的差别，一些受虐狂比买你版本控制集成的力量，而喜欢维护自定义补丁文 件，用来更新卖主包。（如果你是这样的人，一些人可以帮助你治疗）
从外部Subversion版本库合并的能力，提供了前面说的第一种和第二种方法的混合方法，在这个方法里，你只是维护自定义的卖主包拷贝，而不会 去跟踪卖主发布的镜像（因为纯版本可以通过卖主的Subversion版本库获得），但是你现在要做的就是将这些纯版本的区别应用到你的自定义拷贝，而不 是从乱糟糟的补丁文件中应用。
很不幸，“argeman”没有说“嗨，我发现了这个特性，并且它工作的很好”，这个帖子说明有这样一个潜在的特性，但是却不能够处理合并中要添加 的文件，现在是享受开源软件的快乐的时候了，我花了大约40分钟修改了Subversion的代码，并进行了回归测试，并做了一些后续的相关修改，所以 Subversion 1.5中，希望从外部版本库合并与内部合并会有一样的效果。合并源中的重命名依然会与Subversion一样，当从外部版本库合并时合并跟踪逻辑会被绕 过，但合并在大多数情形下都会成功完成。
About the Author
C. Michael (Mike) Pilato has been on the Subversion project as a committer since 2000. Mike is one of the co-authors of “Version Control with Subversion” and he is on the board of the non-profit Subversion Corporation.
因为那个网站被GFW屏蔽了，所以请使用其它方式访问吧。
TAG: Subversion subversion merge remote