SVN的Merge命令解析
合并包含两点，首先2个版本库树比较，然后将区别应用到本地拷贝。 这个命令包括3个参数：初始的版本树（通常叫做比较的左边，FROM）最终的版本树（通常叫做比较的右边，TO）一个接收区别的工作拷贝（通常叫做合并的目标，WORK COPY） 迷惑的主要原因是这个命令的名称，术语“合并”不知什么原因被用来表明分支的组合，或者是其他什么神奇的数据混合，这不是事实，一个更好的名称应该是svndiff-and-apply，这是发生的所有事件：首先两个版本库树比较，然后将区别应用到本地拷贝。 其实使用这个功能后的过程是把To的版本和From版本进行对比，然后把之间的差异合并到当前的版本中。比如要把一个分支的修改全部给合并进来，From就应该选择主线创建了分支的那个版本，To就应该选择分支的Head版本。如果版本选择的不正确，比如说From选择了主线的Head版本，就会把所有分支和主线Head不同的文件都覆盖到主线上来，造成主线上修改信息的丢失。
上面一段引用自SVN官方文档，我认为Merge和Update可以理解为通过2种不同策略，生成了一系列actions（add、mod、del、copy等），然后将这些actions应用到用户工作拷贝中的过程。我们假设applyAction是用来完成将actions应用到本地功能的函数：BOOL applyAction (v_base,b1_action,b2_action)； Merge时： v_base是源分支和目标分支（工作拷贝对应的svn分支）公共版本线上的最后版本 b1_action来自于TO和FROM两个版本的比较生成（add,mod,del,mov）
b2_action来自于目标分支上最新版本和v_base版本的比较生成 Update时：
v_base是工作拷贝中版本库的最新版本（和svn最后一次同步的版本）
b1_action来自于目标分支上最新版本和v_base版本的比较生成 b2_action是用户在v_base版本基础上的本地修改 执行actions时，如果b1_action和b2_action修改了同一个文件的同一位置或同一目录，或者其他类似操作，导致SVN无法确定使用哪一个action时，冲突就产生了。
接下来看看svn提供的3种Merge类型：
1. Merge a range of revesions
将同一个分支上若干个版本的修改，应用到本地的工作拷贝中，一个版本对应着一些actions。

2. Reintergrate a branch 将指定分支上的最新版本（TO），与目标分支的最新版本（FROM）对比，然后将变化应用到 本地的工作拷贝中，是第3种合并的一种特例。
3. Merge two different trees
指定FROM和TO两棵版本树，将TO相对于FROM的变化应用到本地的工作拷贝中。 SVN对比TO版本与FROM版本时，首先剔除掉相同的部分，然后将不同的部分使用一系列更新actions来描述，这些action主要包括add，del，mod等，其中：add，TO版本中存在的文件在FROM版本中不存在（TO版本中新增一个文件，或FROM版本中删除一个文件）del，TO版本中不存在的文件在FROM版本中存在（TO版本中删除一个文件，或FROM版本中新增一个文件）mod，同一个文件在TO分支和FROM分支中版本不同时，将产生一个修改文件的action，修改时将使用TO分支中的文件版本 当TARGET分支（接收区别的工作拷贝对应的分支）与FROM分支相同时，只有工作拷贝目录中的修改未提交时，才可能产生冲突，否则所有差异将直接使用TO分支中的版本。此时，一个分支actions来自于TO和FROM的比较，另一个分支actions来自于用户工作拷贝的版本和FROM版本的比较。相当于在工作拷贝目录直接执行Update命令，只是此时的actions来自于TO和FROM的比较，而不是当前分支的HEAD版本和本地版本库版本的比较。 当TARGET分支既不是FROM分支，也不是TO分支时，不论本地拷贝目录中的修改是否提交，都有可能产生冲突。这是一个最复杂的merge操作，一个分支actions来自于TO和FROM的比较，另一个分支actions则来自于TARGET的HEAD版本和2个分支祖先版本的比较。若TO和FROM分支修改了同一个文件，合并操作将产生冲突，SVN将推荐使用TO分支中的版本。


【测试】一、合并兄弟版本1. 从trunk创建分支branch_5.1, branch_5.22. branch_5.1修改1.txt3. branch_5.2修改3.txt4. 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 version2. mod 3.txt as branch_5.1's version3. mod 4.txt as branch_5.1's version
结果：updated 1.txtupdated 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 version3. mod 4.txt as branch_5.2's version（同trunk版本，无变化）
结果：updated 3.txt
二、合并父子版本1. 从branch_op创建branch_5.0分支2. branch_5.0新增11.txt3. branch_5.0删除1.txt4. branch_5.0修改3.txt5. branch_op新增12.txt6. branch_op删除2.txt7. 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，（本地文件不存在）