‘壹’ svn 命令行怎么解决冲突
解决版本冲突的命令。在冲突解决之后，需要使用svn resolved来告诉subversion冲突解决，这样才能提交更新。冲突发生时，subversion会在Work Copy中保存所有的目标文件版本（上次更新版本、当前获取的版本，即别人提交的版本、自己更新的版本、目标文件。假设文件名是sandwich.txt，对应的文件名分别是：sandwich.txt.r1、
sandwich.txt.r2、sandwich.txt.mine、sandwich.txt）。同时在目标文件中标记来自不同用户的更改。
解决冲突的办法：
- 手动解决：冲突发生时，通过和其他用户沟通之后，手动更新目标文件。然后执行svn resolved filename来解除冲突，最后提交。
- 放弃自己的更新，使用别人的更新。使用最新获取的版本覆盖目标文件，执行svn resolved filename并提交。
- 放弃自己的更新，使用svn revert，然后提交。在这种方式下不需要使用svn resolved。
对于svn resolved命令需要非常小心，必须是非常确定冲突已经解决才能使用。否则，会导致Subversion以为冲突解决，而使代码库不正确。 解决冲突详细文档:
http://svnbook.subversion.org.cn/1.2/svn.tour.cycle.html#svn.tour.cycle.resolve 解决冲突（合并别人的修改）
我们可以使用svn status -u来预测冲突，当你运行svn update一些有趣的事情发生了：
$ svn update U INSTALL G README C bar.c
Updated to revision 46.
U和G没必要关心，文件干净的接受了版本库的变化，文件标示为U表明本地没有修改，文件已经根据版本库更新。G标示合并，标示本地已经修改过，与版本库没有重迭的地方，已经合并。
但是C表示冲突，说明服务器上的改动同你的改动冲突了，你需要自己手工去解决。 当冲突发生了，有三件事可以帮助你注意到这种情况和解决问题： ● Subversion打印C标记，并且标记这个文件已冲突。
● 如果Subversion认为这个文件是可合并的，它会置入冲突标记—特殊的横线分开冲突的“两面”—在文件里可视化的描述重叠的部分（Subversion使用svn:mime-type属性来决定一个文件是否可以使用上下文的，以行为基础合并，更多信息可以看“svn:mime-type”一节）。
● 对于每一个冲突的文件，Subversion放置三个额外的未版本化文件到你的工作拷贝：
● filename.mine
● 你更新前的文件，没有冲突标志，只是你最新更改的内容。（如果Subversion认为这个文件不可以合并，.mine文件不会创建，因为它和工作文件相同。） ● filename.rOLDREV
‘贰’ svn 命令行怎么解决冲突
工程师A修改了a.txt的第一行，提交了。
工程师B也修改了a.txt的第一行，然后执行svn up，这时SVN提示了：（以下，你开始扮演工程师B的角色了）
$ svn up
在 “a.txt” 中发现冲突。
选择: (p) 推迟，(df) 显示全部差异，(e) 编辑,
(mc) 我的版本, (tc) 他人的版本,
(s) 显示全部选项:
我一般选择p（推迟），即引入冲突到本地，不过不会影响到SVN服务器端，可以放心。
OK，开始解决冲突了。
这时，会生成几个文件：
a.txt a.txt.mine a.txt.r6328 a.txt.r6336
其中a.txt中包含了工程师A、B的所有修改，以<<<<<<<、=======、>>>>>>>分隔。
a.txt.mine是工程师B的修改，也就是未update前的a.txt。
a.txt.r6328 是工程师A提交前的版本，即未导致冲突的版本。
a.txt.r6336是工程师A提交后的版本，即导致冲突的版本。
一般，查看a.txt就可以看到冲突的详情了：
[yicheng@chengyi svntest]$ cat a.txt
<<<<<<< .mine
i also modify ,agndagnagasdg;
=======
i modify this line;
>>>>>>> .r6336
以上，<<<<<<< .mine和=======之间是工程师B（当前的“你”）修改的内容，=======与>>>>>>> .r6336之间是工程师A修改的内容。这时，最好的办法是，叫上工程师A，你们一起确定这些修改是否都需要，是否相互兼容，然后留下需要的部分，删 除<<<<<<< .mine、=======和>>>>>>> .r6336。
然后，测试，测试！确定没问题之后，就可以告诉SVN，你解决冲突了：
svn resolve –accept working a.txt (该命令会删除a.txt.mine a.txt.r6328 a.txt.r6336）
svn ci -m ’some comment’ a.txt
这里需要注意的是，a.txt.mine a.txt.r6328 a.txt.r6336这几个文件的存在代表着有冲突产生。如果不解决冲突，就手工删除它们，SVN服务器也会很傻的认为你解决了冲突，允许你继续之后 的工作。但是，冲突依旧存在，你的a.txt中不但有别人的修改，还有那些讨厌的<=>符号。
在冲突未解决前，试图提交代码是肯定会失败的：
$ svn ci -m ”
svn: 提交失败(细节如下):
svn: 提交终止: “/path/to/svntest/a.txt” 处于冲突状态
在使用svn update 的时候，会出现如下一些信息：
$ svn update
U INSTALL
G README
C bar.c
Updated to revision 46.
那么，U 开头的信息提示你，这个文件在你本地没有修改过，文件已经根据版本库的新版本更新了。G 开头的信息提示你，这个文件在你本地已经修改过，但是和版本库中对应的版本并没有冲突的地方，svn已经合并更新了。而C 开头的信息提示你，这个文件有点麻烦，你在本地的修改和版本库中的版本修改的地方重叠了，也就是说，你修改了某一行，你的同事也修改了同一行。这个就需要你自己手工去解决了。当冲突发生时，要注意到有三件事情可以帮助你解决问题。
‘叁’ linux 下得 svn 因为冲突被锁定了，怎么解开
你清理下啊，然后继续Down。或者直接把SVN的隐藏配置全部删除，从新Down
‘肆’ svn有冲突怎么解决
在团队开发中很多情况都会出现，下面就来一个一个的讲解一下svn中的一下应用，以及遇到问题后如何解决。在Myeclipse中一定要有安装svn，可以在线安装也可以离线安装。
项目一定要是在svn中检出出来的，还有就是做过修改的，不管会别人修改的还是自己修改的，这样才能看出来有没有差别，然后右击项目找打Team的与资源库同步，这样就能进入同步的界面，我们就从这里开始分析。
在途中最重要的是要分析一下这个区域的东西。
分析：第一个图标是重新同步，如果在你同步的过程中还有人提交了文件，那么点击这个就会重新同步；第二：一个加号的那个是你自己有没有添加文件，如果有添加的文件上就会出现一个加号图标，减号也一样，如果你删除了文件上一样会出现一个减号的图。第三：蓝色的图标是别人提交的东西；第四：想右的灰色箭头是你要提交的东西或者是修改的东西；第五：如果是全部的；而第六个红色的箭头的是别人的东西和你提交的东西改到了同一个地方。
其实红色箭头是需要处理的，这是需要双击文件，如果在两个文件区域没有红色的区域那就可以直接更新，然后在提交，如果有红色的区域，你需要解决一下冲突，你可以把你写的东西换到其他的行中，这样就不会冲突了，也可以两个改的相通即可。