SVN樹沖突和文件沖突解決方法簡明介紹
本節簡單介紹一下SVN文件沖突和SVN樹沖突在本地的解決方法，在這里和大家分享一下，看完本文你肯定有不少收獲，希望本文能教會你更多東西，讓我們一起來學習SVN文件沖突和SVN樹沖突的解決方法吧。
1.本地刪除，當更新時有刪除進入開發人員A將文件Foo.c改名為Bar.c并將其提交至版本庫中。
開發人員B將文件Foo.c改名為Bix.c
更新開發人員B的工作副本會導致樹沖突:
Bix.c被標記為添加(包括其歷史記錄)。
Bar.c被添加到工作副本中，其狀態為‘正常’。
Foo.c被標記為刪除并且產生一個SVN樹沖突。
要解決這個沖突，開發人員B必須找出沖突的文件Foo.c經過改名/移動后在版本庫中的新文件名是什么。可以使用日志對話框來完成這個任務。
然后，開發人員B需要決定Foo.c的新文件名中的哪一個需要保留-開發人員A改的那個還是他自己改的那個。
在開發人員B手工解決沖突后，使用沖突編輯對話框中的按鈕將樹沖突標記為已解決。
本地缺少，當合并時有更改進入開發人員A在主干上工作，修改Foo.c并將其提交至版本庫中
開發人員B在分支上工作，將Foo.c改名為Bar.c并將其提交至版本庫中
合并開發人員A的主干更改到開發人員B的分支工作副本會導致SVN樹沖突:
Bar.c已經存在于工作副本中，其狀態為‘正常’。
Foo.c被標記為缺少并產生SVN樹沖突。
要解決這個沖突，開發人員B要在沖突編輯對話框中標記文件為已解決，這樣就會將其從沖突列表中刪除。她接下來需要決定是否將缺少的文件Foo.c從版本庫中復制到工作副本中，是否將開發人員A的對Foo.c的更改和合并到改名后的Bar.c或者是否通過標記沖突為已解決來忽略更改什么事也不做。
注意，如果你將缺少的文件從版本庫中復制到工作副本中然后再標記為已解決，你復制下來的文件將被再次刪除。你必須先解決沖突。
2.本地更改，當合并時有刪除進入開發人員A在主干上工作，將Foo.c改名為Bar.c并將其提交至版本庫中
開發人員B在分支上工作，修改Foo.c并將其提交至版本庫中
當文件夾改名時有類似的案例，但是在Subversion1.6中還未被識別...
開發人員A在主干上工作，將父文件夾FooFolder改名為BarFolder并將其提交至版本庫中。
開發人員B在分支上工作，在她的工作副本中修改Foo.c。
合并開發人員A的主干更改到開發人員B的分支工作副本會導致SVN樹沖突:
Bar.c被標記為添加。
Foo.c被標記為修改并產生SVN樹沖突。
開發人員B現在需要做出決定是否接受開發人員A作出的結構改變并且合并她的更改到新結構下適當的文件中，或者直接放棄開發人員A的更改并保留本地文件。
要合并她的本機更改到新布局中，開發人員B必須先找出沖突的文件Foo.c經過改名/移動后在版本庫中的新文件名是什么。可以通過適用于合并源碼的日志對話框來完成這個任務。沖突編輯器僅顯示工作副本的日志因為它不知道將哪個路徑的更改合并進來，所以你需要自己找到它。更改必須要手工合并，因為沒有辦法自動的或者簡單的完成此操作。一旦更改移植完畢，沖突的路徑就是多余的并且可以刪除。在此案例中，使用沖突編輯對話框中的刪除按鈕進行清理并將沖突標記為已解決。
如果開發人員B認為A的更改是錯誤的，那么在沖突編輯對話框中她必須選擇保留按鈕。這樣就會標記沖突的文件/文件夾為已解決，但是需要手工刪除開發人員A的更改。又是通過日志對話框幫助追蹤哪些文件移動了。
本地刪除，當合并時有刪除進入開發人員A在主干上工作，將Foo.c改名為Bar.c并將其提交至版本庫中
開發人員B工作在分之上，將Foo.c改名為Bix.c并將其提交至版本庫中
3.合并開發人員A的主干更改到開發人員B的分支工作副本會導致SVN樹沖突:
Bix.c被標記為正常(未修改)狀態。
Bar.c被標記為添加(包括其歷史記錄)。
Foo.c被標記為缺少并且產生樹沖突。
要解決這個沖突，開發人員B必須先找出沖突的文件Foo.c經過改名/移動后在版本庫中的新文件名是什么。可以通過適用于合并源碼的日志對話框來完成這個任務。沖突編輯器僅顯示工作副本的日志因為它不知道將哪個路徑的更改合并進來，所以你需要自己找到它。
然后，開發人員B需要決定Foo.c的新文件名中的哪一個需要保留-開發人員A改的那個還是他自己改的那個。
在開發人員B手工解決沖突后，使用沖突編輯對話框中的按鈕將樹沖突標記為已解決。本節關于SVN文件沖突和SVN樹沖突內容講解完畢，請關注本節其他相關報道。
【編輯推薦】
