經常有人會說，樹沖突是很難解決的一類沖突，其實一旦了解了其原理，要解決也不難。先回顧下對於樹沖突的定義。
樹沖突：當一名開發人員移動、重命名、刪除一個文件或文件夾，而另一名開發人員也對它們進行了移動、重命名、刪除或者僅僅是修改時就會發生樹沖突。
出現沖突時，一般會提示沖突的信息是什么。過后我們可以使用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的修改時會提示沖突。重命名后的文件被標記為新增，原來文件被標記為樹沖突。
解決：通過日志查找到文件被改名的時刻，兩人協商后解決。
