经常有人会说，树冲突是很难解决的一类冲突，其实一旦了解了其原理，要解决也不难。先回顾下对于树冲突的定义。
先介绍一下概念
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的修改时会提示冲突。重命名后的文件被标记为新增，原来文件被标记为树冲突。
解决：通过日志查找到文件被改名的时刻，两人协商后解决。
二、 2
1、将冲突文件目录重命名，重新更新，
2、将冲突文件 svn resolved
3、svn commit
谷歌给出的解决办法参考：
1、http://blog.csdn.net/hantiannan/article/details/5306194
Eclipse内SVN 右击工程目录–>team–>Show Tree Conflict–>在Eclpise中会出现一个Tab视图显示Tree Conflict的内容，一个一个选择列表中的冲突右击将其标志为已解决，然后回到项目再提交更改就可以了。
2、http://eyejava.iteye.com/blog/356109 （更详细办法）