SVN树冲突及解决方式（ eclipse操作详解 ）

如何判定我是否有SVN树冲突？

1.在eclipse中发现红绿箭头图标



- 此图标表示有目录树冲突的文件。一般在最近一次更新后，资源库上的文件被移动、删除或重命名。
A file that has a tree conflict. These are typically files that have local changes, but have since been moved, removed, or renamed in the repository since
the last local copy update.
2.eclipse更新代码后日志(留意console窗口输出）中输出了以下内容 （Tree conflicts )



3.TortoiseSVN点击Resolve 时显示 tree conflicts

什么是树冲突 ？

（以下分隔线内容节选自网络）
-----------

树冲突：当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。

出现冲突时，一般会提示冲突的信息是什么。过后我们可以使用svn st来查看当前状态。svn st的各种状态代表什么，请参考此博文svn
st状态详解。

先介绍一下概念

Delete ： 其中目录结构变化，都认为是Delete
Edit： 是指修改文件
Local ： 是你本地修改
Incoming ：是别人修改，你要Update或Merge进来。
这样应该有4个组合，但是Edit对Edit的组合应该是File Conflict，这个容易解决，不在Tree Conflict 讨论范围，所以有3种组合。再需要区别Update和Merge，就有了6种情况。分别是
Local delete, incoming edit upon update
Local edit, incoming delete upon update
Local delete, incoming delete upon update
Local missing, incoming edit upon merge
Local edit, incoming delete upon merge
Local delete, incoming delete upon merge
分别对这几种情形解释如下：
1.Local delete, incoming edit upon update（本地删除，更新后传入修改）
产生原因：1.A修改文件Foo.c后提交到版本库中，B将Foo.c重命名为Bar.c或者删除了Foo.c或者直接将Foo.c的父目录Foo直接删除 2.B更新工作副本会提示该冲突，在working copy显示为Foo.c在本地删除，被标记为冲突。如果是重命名，则Bar.c被标记为新增，但是不包括A的修改。
解决：A与B要确认是否采用A的修改与是否重命名。如果采用A的修改，并且要重命名则修改后，标记冲突解决，svn resolved，最后提交；如果不采用A的修改，直接标记冲突解决提交即可。
2.Local edit, incoming delete upon update （本地编辑，更新后传入删除）
产生原因：1.A对Foo.c重命名为Bar.c并提交到版本库（或者A将Foo.c的上级目录Foo修改为Bar），B在他的工作副本中对Foo.c进行修改。2.B提交前更新，会提示如此错误。
解决：同样需要两个人进行协商后修改。
3.Local delete, incoming delete upon update （本地删除，更新后传入删除）
产生原因：1.A将Foo.c重命名为Bar.c后提交，B对Foo.c重命名为Bix.c。2.B更新本地工作副本是会提示该树冲突。
解决：通过日志查找文件被删除即重命名的原因，A与B协商后最终确认采用哪个名称。
4.Local missing, incoming edit upon merge （本地丢失，合并后传入修改）
产生原因：1.A在主干上修改Foo.c，B在分支上将Foo.c重命名为Bar.c。2.B合并A在主干上的修改。
解决：B先标记冲突解决，然后将Foo.c拷贝至本地，将A的修改合并至自己的文件中或者直接放弃A的修改，采用自己的修改。
5.Local edit, incoming delete upon merge （本地修改，合并后传入删除）
产生原因：1.A将Foo.c重命名为Bar.c(或者将Foo.c的父目录Foo改为Bar)，B在分支上修改Foo.c。2.B合并A的修改时提示该冲突。Bar.c被标记为增加，Foo.c被标记为冲突。
解决：同样根据日志查找到修改的源头，两人协商后解决。
6.Local delete, incoming delete upon merge （本地删除，合并后传入删除）
产生原因：1.A在主干上将Foo.c重命名为Bar.c，B在分支上将Foo.c重命名为Bix.c。2.B合并A的修改时会提示冲突。重命名后的文件被标记为新增，原来文件被标记为树冲突。
解决：通过日志查找到文件被改名的时刻，两人协商后解决。

---------------------
（节选结束）
实际上除了上述描述情况外还有其他情况，比如
local obstruction,incoming add upon merge
此种情况解释可参见以下链接，其中提到了冲突发生的原因及可选解决方案（使用命令行）： https://little418.com/2009/05/svn-local-obstruction-incoming-add-upon-merge.html
其中主要原因翻译是：
这个特殊的冲突消息是在同一个文件被添加到您合并的位置以及自上次合并后的合并位置时创建的。由于这些冲突文件有完全不同的历史和不常见的状态（因为如果文件已经在你的分支添加存在），SVN不能提供解决建议。这也就是为什么您将看到没有合并向左或合并正确的文件的操作选择。

如何解决树冲突 ？

首先要确定这个冲突采取哪种方案解决，然后再进行操作。

解决树冲突的判断与决策（解决方案）：

发生树冲突时，如果是多方操作引起的树冲突，一般可以由冲突双方协调解决以哪个版本为准或者合并代码，然后再进行替换或者编辑操作。

当某些树冲突非多方同时操作树引起时（比如合并分支时发生或由于之前不规范的合并导致），可直接以某个版本为准更新代码。

解决树冲突的操作：
1. 解决树冲突时，如果文件数量不多，可采取手工编辑或者替换目录文件，然后通过标记为resolve解决
* 发生树冲突的文件可以直接标记为resolve（不编辑或者替换解决实际存在的冲突） ,这种情况下一般会丢失你的信息！（这也就是很多人冲突后会把别人的代码给覆盖了的原因）
* 未解决树冲突时（未标记为resolve），将无法提交代码！
2. 当文件数量多时，我们甚至很难找到哪些文件发生了树冲突，此时可以借助一些工具或者插件来进行，下面介绍的是eclipse的插件subclipse的操作方法。
首先： 右键项目 > Team > show tree conflicts



此时将会显示 所有的 树冲突文件 ，右键某个冲突文件 > 点击resolve ，即可选择对冲突文件（或目录）的操作。
当两个版本文件不一致时，可选择 直接以其中一个版本为准替换。



或者对比文件差异（compate....），此时将进入编辑界面。



当文件相同时，可以直接标记为解决。

tips:
* eclipse有另外的一个svn插件
* 本文中使用的subclipse版本为：4.2.3
* 标记解决后，图标

将会变成 * 号图标，当所有冲突解决后，即可提交代码。

3.可使用命令行解决，参考链接：
http://www.jianshu.com/p/e3cc83ca512d