Subversion合并跟踪

Subversion 1.5支持合并跟踪，本文将对什么是合并跟踪，及其对你们组织具备的意义提供了高级的总体看法，我将会从许多基本的解释开始，如果你熟悉分支与合并，请掠过第1段。

1. 什么是分支与合并？

开发团队经常会在多个并行线上开发，叫做”分支”，一个分支从拷贝开发项目（或一个目录）所有的文件开始，然后开始单独的维护这个拷贝，文件开始都是相同的，但经过一段时间，它们将会不同，因为不同的开发者在不同分支做出了修改。

为什么分支？你或许在Subversion创建一个分支用来维护产品发布，同时为下一个版本工作。为什么？下一个版本会有新的特性，但是在维护分支你只接受bug修改。另一个用例是开发复杂的新特性，而它会将使得开发构建不稳定，通过在不同分支开发，你将其他开发者从可能的构建失败中分离出去。 Subversion自己的合并跟踪特性在一个分支上开发了差不多一年。

Graph 1. 两个分支的主线开发 (trunk)

Subversion一直支持分支，但与其他系统不同，它不会真正的拷贝文件，那样会快速加大版本库的体积。相反，Subversion会创建一个到原来已有目录的快速引用，只是记录分支和trunk的文件修改，这样的结果是创建分支非常迅速，版本库几乎不会增加大小。

有些时候，代码需要合并。例如，一个开发者在维护分支上修订了一个bug，你会希望将修改合并到主开发线上，否则，你的下个发布还会有这个bug。另一个例子是在分支上开发一个新特性。像我们说的，Subversion自己的合并跟踪特性是在分支上开发的，在2007年2月，这个特性足够稳定，然后合并到了trunk。

Graph 2. 合并代码

让我们看一个简单的合并实例，这是我们的代码：

trunk的代码 (主码基)  

main() {     printf(”hello， wordn”); }

现在我们做一个分支，从用户的角度会有两份代码：

2. Subversion与合并

像分支，Subversion一直支持合并，如果你要求它可以自动完成许多工作。但是Subversion不会”记住”什么代码从什么分支在什么时候合并，尽管分支与合并在Subversion中工作很好，但是合并跟踪特性的添加解决了许多限制：

    重复合并，假设你有一个特性分支与主干同步，没有合并跟踪时，你必须小心的（且手工的）记录哪些修订版本已经合并，这会非常乏味，而且如果你忘了合并特定修改或是创建叫做”伪造的冲突”的东西，这意味着文件没有正确的合并，结果修订版本有错误。     审计。当你合并一个特性分支回trunk，trunk的历史只记录了合并的发生，但是不知道合并了什么，这样很难准确找出合并了什么到trunk。

subversion