SVN的Merge命令解析

合并包含两点，首先2个版本库树比较，然后将区别应用到本地拷贝。
这个命令包括3个参数：

初始的版本树（通常叫做比较的左边，FROM）
最终的版本树（通常叫做比较的右边，TO）
一个接收区别的工作拷贝（通常叫做合并的目标，WORK COPY）

迷惑的主要原因是这个命令的名称，术语“合并”不知什么原因被用来表明分支的组合，或者是其他什么神奇的数据混合，这不是事实，一个更好的名称应该是svndiff-and-apply，这是发生的所有事件：首先两个版本库树比较，然后将区别应用到本地拷贝。

其实使用这个功能后的过程是把To的版本和From版本进行对比，然后把之间的差异合并到当前的版本中。比如要把一个分支的修改全部给合并进来，From就应该选择主线创建了分支的那个版本，To就应该选择分支的Head版本。如果版本选择的不正确，比如说From选择了主线的Head版本，就会把所有分支和主线Head不同的文件都覆盖到主线上来，造成主线上修改信息的丢失。

上述内容引用自SVN官方文档，我认为Merge和Update可以理解为通过各自不同的策略，生成了一系列actions（add、mod、del、mov），然后将这些actions应用到用户工作拷贝中的基准版本上，如下图:







remote_branch和local_branch可以看成是对ver_base版本同时进行操作的2个逻辑分支，branch_remote_actions来自于update、merge等命令；branch_local_actions来自于用户本地版本与ver_base版本的比较，本地版本即用户工作拷贝的当前版本状态，注意与本地版本库的区别。

Update时：
base_line：当前工作分支
ver_base：当前工作分支本地版本库的最新版本
branch_remote_actions：当前工作分支服务端最新版本与ver_base版本的比较生成
branch_local_actions：当前工作分支本地版本与ver_base版本的比较生成

Merge时：
base_line：branch_remote和branch_local的公共版本线（只要来自于同一项目，必定存在公共版本）
ver_base：SVN公共版本线上的最后一个版本

branch_remote_actions：由一组或多组TO和FROM版本比较生成
branch_local_actions：TARGET分支的本地版本与ver_base版本比较生成（TARGET分支即接收区别的工作拷贝对应的SVN分支）

最后看看svn提供的3种Merge类型：

1. Merge a range of revesions

将某个分支上的一些修改，应用到本地的工作拷贝。
branch_remote由用户手工选择，branch_remote_actions由多组TO和FROM版本（用户手工选择的版本）比较生成。

2. Reintergrate a branch
将某个分支上的所有修改，应用到本地的工作拷贝。
branch_remote由用户手工选择，则TO为branch_remote：HEAD，FROM为base_line：ver_base

3. Merge two different trees

将手工指定的FROM和TO两个版本树的差异，应用到本地的工作拷贝。
TO和FROM均有由用户手工选择，branch_remote_actions由TO和FROM版本对比生成。当TARGET与FROM为同一分支时，ver_base等于
FROM。

SVN对比TO与FROM版本时，首先剔除掉相同的部分，然后将不同的部分使用一系列更新actions来描述，这些action包括
add，del，mod等，其中：

add，TO版本中存在的文件在FROM版本中不存在（TO版本中新增一个文件，或FROM版本中删除一个文件）
del，TO版本中不存在的文件在FROM版本中存在（TO版本中删除一个文件，或FROM版本中新增一个文件）
mod，同一个文件在TO分支和FROM分支中内容不同时，将产生一个修改文件的action，修改时将使用TO分支中的文件版本（文件内容不同，可能是TO和FROM其中之一修改了此文件，也有可能是双方都修改了这个文件，前者将产生一个使用TO分支中版本修改此文件的action，而后者将导致冲突的，SVN推荐使用TO分支中的版本修改解决冲突）

【测试】

一、测试版本对比产生的actions
1. 从branch_op创建branch_5.0分支
2. branch_5.0新增11.txt
3. branch_5.0删除1.txt
4. branch_5.0修改3.txt
5. branch_op新增12.txt
6. branch_op删除2.txt
7. branch_op修改3.txt

case1：TARGET: trunk, FROM: branch5.0:HEAD，TO: branch_op:HEAD
结果：
1. del 11.txt，产生冲突（本地文件不存在）
2. add 1.txt，产生冲突（本地文件已存在）
3. mod 3.txt，产生冲突（修改同一文件）
4. del 2.txt，正常
5. add 12.txt，正常

case2：TARGET: trunk, FROM: branch_op:HEAD，TO: branch_5.0:HEAD
结果：

1. add 11.txt，正常
2. add 1.txt，正常
3. mod 3.txt，产生冲突（修改同一文件）
4. add 2.txt，（本地文件已存在）
5. del 12.txt，（本地文件不存在）

二、测试action的执行结果
1. 从trunk创建分支branch_5.1, branch_5.2
2. branch_5.1修改1.txt
3. branch_5.2修改3.txt
4. branch_5.1修改4.txt

case1：TARGET: trunk, FROM: branch_5.2:HEAD, TO: branch_5.1:HEAD
版本差异产生的action集：
1. mod 1.txt as branch_5.1's version
2. mod 3.txt as branch_5.1's version
3. mod 4.txt as branch_5.1's version

结果：
updated 1.txt
updated 4.txt

补充：
因为branch_5.1中的3.txt和trunk中的版本相同，因此Merge执行的结果中，3.txt状态无变化，似乎action2并不存在；
若trunk修改了3.txt，不论修改是否提交，action2将导致冲突，这证明action2操作确实存在，只是当文件内容没有变化时，
action2不会执行。因此，我们发现了这样一个事实：actions在执行时，将比较工作拷贝中的版本决定是否执行。

case2：TARGET: trunk, FROM: branch_5.1:HEAD, TO: branch_5.2:HEAD

版本差异产生的action集：
1. mod 1.txt as branch_5.2's version（同trunk版本，无变化）
2. mod 3.txt as branch_5.2's version
3. mod 4.txt as branch_5.2's version（同trunk版本，无变化）

结果：
updated 3.txt