如今是一个团结协作的时代，开发一个系统，往往会多人协作共同完成。版本管理是必不可少的，常用的软件有Git，SVN等。今天说一下，SVN管理版本时，如果出现冲突后，如何快速解决冲突。
首先说明一个问题，有一种情况无论如何都不会出现冲突。假如有一个叫qaz的程序员，他checkout了版本库，这样他拥有了一个工作副本。然后，他修改了某个文件IMRoot.cs，commit到SVN，并且这个文件保证不会有其他人在他们的工作副本修改并提交到SVN。这种情况下，无论qaz 如何修改IMRoot.cs ，在commit时都不会发生冲突。
以上说了一种不会出现冲突的情况，那么什么应用场合可能会出现冲突呢？假如程序员wsx 他会修改文件 IMRoot.cs 并commit 到SVN，此时可能会引发冲突。
实例分析
下面，我们根据实际应用场合，模拟出现冲突，到如何通过SVN提供的Edit Conflicts 界面，通过颜色标识和操作按钮，快速准确地合并解决冲突。
开始，IMRoot.cs 文件主题内容是这样的，命名空间为了理解方便省略掉。
qaz 在文件的第14 行做了修改，其他的未作任何改动，并且将修改commit到了SVN。
wsx 在在第19行做了修改，修改如下，
并且在提交前update了（注意因为这个文件已经被qaz 做了修改，所以wsx 如果commit前不update，SVN是不允许提交的），然后commit，此时，SVN不会引发冲突，因为修改不是在同一行。SVN将qaz 的修改合并到了wsx 拥有的工作副本中，合并后文件如下所示，
为了故意引发冲突，假设qaz 和 wsx 同时都修改了第29行。前者修改第29行为如下，并且commite 到了SVN中
后者修改也同时修改了这一行，这意味他并没有update 这个文件，
然后他commit 到SVN时，提示先update ,紧接着出现冲突，如下所示，
此时，找到这个文件，右键选择Edit conflicts 按钮，弹出编辑冲突的界面，这才到了重点！
从上图可以看到，主要有3个子窗口组成，左上Theirs 为SVN版本库中（也就是qaz 刚才修改提交到SVN的版本），右上 Mine 为 wsx （正在提交到SVN发现冲突的他）的工作副本文件，下方为合并他俩的文件后的显示窗口。
以下为这3个窗口的局部视图，依次为左上，右上，下方，
左上
右上
下方
当面对以上3个窗口时，还是容易让人发蒙，尤其是文件比较复杂，冲突一大片，各种颜色掺杂在一起，不知如何下手，害怕把其他文件意外破坏和文件合并错误。那么怎么办呢？我们不妨先从简单的文件冲突入手，彻底理解各种颜色的含义，冲突行是如何标记的，这样我们才敢大胆地使用这个界面进行代码合并操作，不用担心合并后，把别的文件无辜干扰了或者出现合并错误的问题。
仔细观察以上3个窗口，我们发现，28行和29行之间多出来一行，即橙色行，并且Theirs 和Mine 都含有这一行，这个是未冲突前，此行的内容，即刚开始的版本。第29行是爆红行、冲突行，相应字段还是黄色警示，并且在第3个窗口（下方窗口）第29行全是？？？？？这种符号，意味着无法合并他俩对此行的同时修改，需要我们判断，要么采取Theirs 的，要么采取Mine 的，要么采取上一版本，要么重新商量一个相同的。SVN也提供了几个方便的右键按钮，提示如何做出这些选择，
use this text block ： 选取选中行的内容 use this whole file ：选取选中行所在文件的全部内容 use text block from mine before theirs ：先用Mine的内容，后面接着用theirs的
假如第29行我们想采用qaz 的修改，那么，我们在左上窗口，选中第29行，右键选择 use this text block ，然后下方的视图变为如下，
第29行由一行？？？？？？变为左上窗口第29行的内容，颜色由爆红变为了浅绿色。这时候注意观察，在上一行橙色显示内容代表什么意思，注意最左侧有个 “-”提示，代表此行不会纳入合并文件中。
假如第29 行，我们都想纳入qaz 和wsx 的修改，此时我们在左上窗口选择，use text block from mine before theirs ，即先用Mine的内容，后面接着用theirs的，选择后下方窗口合并内容如下，
可以看到，第29行，先显示Mine的，然后显示Theirs的。
这些操作后，我们点击上方的Mark as Resolved 按钮，然后保存即可。这样冲突就被解决掉了。然后wsx 再commit 自己的内容到SVN。
)
