svn如何解决分支冲突

方法/步骤
1
我个人认为不管是提交、更新、编辑冲突第一个 *** 作都应该是和资源库进行同步，项目右键==》Team==>于资源库同步（这里需要注意的是你的开发环境中已经正常集成了SVN，可以直接在myeclipse中使用）具体 *** 作如下图
2
与SVN资源库同步后，就会在界面上显示如你当前的项目需要更新多少文件、提交多少文件。如下图：
3
到这里我们知道了情况后就是 *** 作顺序的问题，我个人建议先更新没有冲突的文件到本地，再编辑冲突文件、最后测试确认无问题再提交到SVN上。在这个界面上更新和提交的 *** 作我就不详细说明了，我这里想详细说说编辑冲突。如下图
4
在
上面的中需要重点说明的是2和3编辑冲突是会出现蓝色和红色的对比框。蓝色的可以点击中间的小正方形从服务器移动到本地，红色的移动后还得手动
修改成一样的，要不然还会出现冲突。这些事做完了保存一下，要保证你本地的已经有的部分和服务器上一致，这次修改或者需要提交的是服务器上没有的。到这里
还要像图3那样标记一下为合并。
5
最后一步其实就是提交，但是我建议在提交之前还是本地运行一下看看有没有运行错误、报错之类的。确认没有问题后就回到那个资源库对比界面选择提交。
>工程师A修改了atxt的第一行，提交了。
工程师B也修改了atxt的第一行，然后执行svn up，这时SVN提示了：（以下，你开始扮演工程师B的角色了）
$ svn up
在 “atxt” 中发现冲突。
选择: (p) 推迟，(df) 显示全部差异，(e) 编辑,
(mc) 我的版本, (tc) 他人的版本,
(s) 显示全部选项:
我一般选择p（推迟），即引入冲突到本地，不过不会影响到SVN服务器端，可以放心。
OK，开始解决冲突了。
这时，会生成几个文件：
atxt atxtmine atxtr6328 atxtr6336
其中atxt中包含了工程师A、B的所有修改，以<<<<<<<、=======、>>>>>>>分隔。
atxtmine是工程师B的修改，也就是未update前的atxt。
atxtr6328 是工程师A提交前的版本，即未导致冲突的版本。
atxtr6336是工程师A提交后的版本，即导致冲突的版本。
一般，查看atxt就可以看到冲突的详情了：
[yicheng@chengyi svntest]$ cat atxt
<<<<<<< mine
i also modify ,agndagnagasdg;
=======
i modify this line;
>>>>>>> r6336
以上，<<<<<<< mine和=======之间是工程师B（当前的“你”）修改的内容，=======与>>>>>>> r6336之间是工程师A修改的内容。这时，最好的办法是，叫上工程师A，你们一起确定这些修改是否都需要，是否相互兼容，然后留下需要的部分，删 除<<<<<<< mine、=======和>>>>>>> r6336。
然后，测试，测试！确定没问题之后，就可以告诉SVN，你解决冲突了：
svn resolve –accept working atxt (该命令会删除atxtmine atxtr6328 atxtr6336）
svn ci -m ’some comment’ atxt
这里需要注意的是，atxtmine atxtr6328 atxtr6336这几个文件的存在代表着有冲突产生。如果不解决冲突，就手工删除它们，SVN服务器也会很傻的认为你解决了冲突，允许你继续之后 的工作。但是，冲突依旧存在，你的atxt中不但有别人的修改，还有那些讨厌的<=>符号。
在冲突未解决前，试图提交代码是肯定会失败的：
$ svn ci -m ”
svn: 提交失败(细节如下):
svn: 提交终止: “/path/to/svntest/atxt” 处于冲突状态
在使用svn update 的时候，会出现如下一些信息：
$ svn update
U INSTALL
G README
C barc
Updated to revision 46
那么，U 开头的信息提示你，这个文件在你本地没有修改过，文件已经根据版本库的新版本更新了。G 开头的信息提示你，这个文件在你本地已经修改过，但是和版本库中对应的版本并没有冲突的地方，svn已经合并更新了。而C 开头的信息提示你，这个文件有点麻烦，你在本地的修改和版本库中的版本修改的地方重叠了，也就是说，你修改了某一行，你的同事也修改了同一行。这个就需要你自己手工去解决了。当冲突发生时，要注意到有三件事情可以帮助你解决问题。

---