最近在对项目进行重构，另一方又在进行开发。而且项目用的SVN进行的版本控制所以就悲剧了，因为普通的冲突很好解决，但是不普通的冲突还是遇到了，svn中提交文件时出现tree conflicts。
目录结构冲突比较繁琐以下是产生目录结构冲突的表现：
1、本地删除，更新后传入修改
产生原因：
(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、本地编辑，更新后传入删除
产生原因：
(1)、A对Foo.c重命名为Bar.c并提交到版本库（或者A将Foo.c的上级目录Foo修改为Bar），B在他的工作副本中对Foo.c进行修改。
(2)、B提交前更新，会提示如此错误。
解决：同样需要两个人进行协商后修改。
3、本地删除，更新后传入删除
产生原因：
(1)、A将Foo.c重命名为Bar.c后提交，B对Foo.c重命名为Bix.c。
(2)、B更新本地工作副本是会提示该树冲突。
解决：通过日志查找文件被删除即重命名的原因，A与B协商后最终确认采用哪个名称。
4、本地丢失，合并后传入修改
产生原因：
(1)、A在主干上修改Foo.c，B在分支上将Foo.c重命名为Bar.c。
(2)、B合并A在主干上的修改。
解决：B先标记冲突解决，然后将Foo.c拷贝至本地，将A的修改合并至自己的文件中或者直接放弃A的修改，采用自己的修改。
5、本地修改，合并后传入删除
产生原因：
(1)、A将Foo.c重命名为Bar.c(或者将Foo.c的父目录Foo改为Bar)，B在分支上修改Foo.c。
(2)、B合并A的修改时提示该冲突。Bar.c被标记为增加，Foo.c被标记为冲突。
解决：同样根据日志查找到修改的源头，两人协商后解决。
6、本地删除，合并后传入删除
产生原因：
(1)、A在主干上将Foo.c重命名为Bar.c，B在分支上将Foo.c重命名为Bix.c。
(2)、B合并A的修改时会提示冲突。重命名后的文件被标记为新增，原来文件被标记为树冲突。
解决：通过日志查找到文件被改名的时刻，两人协商后解决。
当然当提交的时候有目录冲突就会有tree conflicts报错，这个时候可能你的修改已经不存在了，也就是别人修改的目录移动的文件刚好是你修改的，这样你就悲剧了。我也不知道恢复删除，所以只能再做一遍，所以最好不要改动目录结构，或者改动的时候告诉别人，让别人又准备，否则很悲剧的
这里说解决tree conflicts的问题，解决让后提交才是硬道理
$ svn resolve --accept working -R XXX。
其中XXX为提示冲突的目录，tree conflicts冲突的前缀是 C >这个标识，然后就可以提交了。OK
