SVN中的Branches分支以及Merge 应用举例

come from: http://www.360doc.com/content/12/0816/19/1317564_230547958.shtml

建立Branch分支或者Tag标签
当按照推荐的结构建立的版本库，建立分支以及Tag是很容易的。
 在个人SVN服务器上建立了一个版本库Test，结构以下：


 在个人本地签出checkout，添加一个文件test.txt，而后提交。

 

加入这个时候咱们须要发布一个版本的文件，同时有可能其余人会修改，

但咱们不能影响当前的文件，只能在其修改好后再合并，这种状况下咱们建立一个分支。

这个时候咱们能够发现本地的trunk文件夹的SVN属性的URL已经被Switch到建立的版本的地址了：

执行SVN更新命令，能够查看到，本地branches文件夹下新增文件夹v1.0以及文件夹里面的文件v1.0。

 

修改分支和使用合并Merge功能

修改branches/v1.0下面的文件test.txt，添加一行modified in branch v1.0.而后签入到SVN服务器中：

因为刚才咱们已经将trunk的SVN版本库URL转换到对应的版本，因此这个时候更新trunk文件夹能够看到更新的test.txt文件。
为了做测试，咱们将trunk文件夹switch至对应的trunk地址：

当switch成功后，咱们能够看到trunk下test.txt文件的内容并无任何的更改，这正体现了刚才咱们所说的在分支中的修改不会影响到主干。
下面修改trunk文件夹下的test.txt，添加一行modified in trunk.而后签入到SVN服务器中：

最好咱们将实现一个重要的功能，就是Merge合并功能，将分支合并到主干中，这也是在团队软件开发中咱们常常要使用的功能。
在TortoiseSVN的Revision Graph中能够查看trunk的版本变化图，以下：

从上图能够得出，在版本10的时候咱们建立了分支版本/branches/v1.0，且SVN版本为11，在版本11基础上咱们对分支进行了修改因而有了 版本12，咱们再对trunk下的文件进行修改因而有了版本13，整个SVN目前的版本就为13，这与咱们刚才作的修改是相吻合的。
下面将分支v1.0合并到主干中。
按照咱们目前的状况，选择第二种：

选择v1.0：

而后，以下：

在咱们的此次合并中确定会产生问题，由于咱们对test.txt文件进行了两次修改，于是会产生冲突Conflict，但这在实践中是不该出现这种状况 的，由于创建的分支目的就是修改那些在主干中不会被修改的文件，以便修改完成后合并到主干中。不过不要紧，咱们这里仅是演示而已，因此只需处理下冲突，手 动的将其合并（这在实际中不该该这样不然失去了分支的用途了）：

这个时候能够看到咱们的test.txt文件已经按照我刚才手动处理冲突实现了：

而后将trunk签入到版本库中：

 

若是咱们再去查看branches\v1.0下的test.txt文件它的内容依然是最初在trunk中编辑的内容。 另外再次强调一点：在实际操做中咱们不会对一个分支文件在主干中再次进行修改，不然会形成一些冲突，这样就失去了分支的便利性了；Tag的建立与分支是类s似的，只不过Tag每每仅用于标识特定版本，而不会用于bug修复，增长新特性等情形。