svn作为版本控制软件被广泛用于众多公司的开发团队中，最多的场景就是一个项目上传svn后，一个组内的小伙伴在上边提交和更新代码以及解决冲突，其实这只是发挥了svn的很小的一部分功能。
先稍微介绍一下svn的两种开发和发布的规范：
一 主干修改，分支发布
代码都在trunk上修改，需要发布的时候，从主干上拉出一个版本，如果该版本发现BUG则继续从该分支上修改，并将修改合并到主干上。
二 主干发布，分支修改
任何修改都不能在主干上直接进行，开发新功能，从主干上分支出一个版本，进行开发，发开测试完毕后，在合并到主干上。
个人比较推崇第二种，其优势在于各个分支独立进行，互不干扰，可以使不同开发周期的应用在同一个项目中开发进行。对于同一个应用，a组人开发完毕，b组人只做了一半，这个时候，对于主干修改，分支发布，这样是根本不能发布出去的，而对于主干发布，分支修改，只需要把a组的修改合并回主干就可以发布出去了，b组开发的根本不受影响。
下面介绍一下分支，合并的应用场景，并针对场景进行一个小栗子。
场景1： 采用主干发布，分支修改的规范后，项目要新开发一个功能，这时候我拉开了一个分支，开发完毕后要分支代码合并回主干。
场景2：我在分支的开发过程中，主干被其他的项目组进行较大的改动，为了避免在“正确”（trunk）的道路上走歪了，也为了避免最终合并代码的时候，太过麻烦，我需要将主干的代码合并到分支上来。
场景3：对于同一个文件，同一个方法内的代码合并的时候冲突问题解决。
案例：事先准备工作，我需要在svn创建一个项目test，并创建一个分支test2.0 如图，项目右键--Team-分支
然后刷新一下svn仓库，对比看一下trunk主干和branches分支里面多了一个2.0的test
场景1 分支代码合并回主干。
项目右键-team-先切换到分支代码，然后将分支代码进行改动，然后在切换回主干代码，进行合并操作，如图
然后将分支的修改代码提交svn一下，然后同样切换回主干trunk代码，准备合并。
切换回主干代码后，分支代码修改的地方，主干代码不受影响，还是老样子。
右键team-选择合并，然后选择第二个选项：分支合并到主干
这时候，你就会看到分支的代码被合并到主干上来了，然后提交svn就可以了
场景2：就不介绍了，唯一的区别就是选择合并方式的时候，选择第一个选项就可以了
场景3：冲突解决
再次切换到分支代码，将分支代码更改
然后切换到主干代码trunk，项目右键-team-合并，选择第二项，分支合并到主干，next。就会出现如下图结果，将冲突解决完后，右键-》标记为解决冲突
冲突的代码就解决完了。
最后附带merge input 合并类型截图
摘自：http://blog.csdn.net/liuyifeng1920/article/details/53118183