轉自http://www.cr173.com/html/46224_1.html

TortoiseSVN衝突問題詳解 SVN版本衝突解決詳解

解決版本衝突的命令。在衝突解決之後，需要使用svnresolved來告訴subversion衝突解決，這樣才能提交更新。衝突發生時，subversion會在WorkCopy中保存所有的目標文件版本（上次更新版本、當前獲取的版本，即別人提交的版本、自己更新的版本、目標文件。

開發人員都知道代碼管理工具是開發中一個必不可少的工具，這裏也不廢話詳細介紹了。不管你個人喜歡git還是svn還是其他，但還有一大部分公司在使用svn做代碼管理工具。這裏詳細介紹下SVN提交文件時衝突問題的解決方式。

假設A、B兩個用戶，他們分別從svn服務器中檢出了test1.txt文件，此時A、B、服務器三個地方的test1.txt的版本都是13(我測試環境的當前svn賦予的版本號)。A、B文件的內容如下圖（左A右B）：

接下來，B用戶添加一句話並提交，內容如下：

此時B用戶和服務器的test1.txt的版本都變爲14，只有A用戶的test1.txt的版本還爲13。接下來A用戶添加一句“aa”,然後提交

由於A用戶是在13版本上做的修改，而服務器已經是14版本了，所以會提交失敗：

接下來就是我們要解決的問題了，解決方法分爲以下兩種方式。第一種方式：提交失敗後直接選擇revert，省去了解決衝突問題；第二種方式：提交失敗後選擇更新文件，這時會有衝突問題。詳細介紹如下：

第一種方式：

A放棄自己修改的內容，進行Revert操作，使其test1.txt成爲13版本的最初內容。然後update使其test1.txt成爲14版本，再在14版本上修改提交。操作如下圖：

==》

==>然後再修改提交

第二種方式：

因爲版本過時，提交失敗後。A用戶直接選擇更新操作，結果如下圖所見

（這裏聲明下，不要被文件顯示的圖標所迷惑，這是其他軟件對它做了關聯導致的，沒啥影響）

這裏詳細說一下產生衝突後的這幾個文件，：

test1.txt.mine---這個文件是A用戶在13版本中做了修改要提交的文件。它的內容是：13版本內容+A用戶的修改

test1.txt.r13----這個文件是A用戶最初的13版本的test1.txt。它的內容是：13版本內容

test1.txt.r14----這個文件時svn服務器中test1.txt的最新版本，這裏既是B用戶提交後的14版本。它的內容是：13版本內容+B用戶的修改

test1.txt--------由於A用戶選擇了直接更新，此文件就是svn將最新版本14 與 A用戶的修改合併後的文件。它的內容如下：

接下來說一下如何解決。對於源代碼文件或其他的純文本文件，我們可以將上圖的A用戶test1.txt的內容整理下，使其滿足條件，然後選擇，這時test.txt.mine、test1.txt.r13、test1.text.r14將會消失。用戶A就可以順利提交了。但是，如果 test1.txt是一個非純文本文件，比如excel，這時的test1.txt將沒法手動合併了，不得不放棄自己的修改。可以在test1.txt上右鍵選擇消除掉test.txt.mine、test1.txt.r13、test1.text.r14這三個文件。（點擊Resolve不會更改 test1.txt以及服務器端的內容，僅僅是消除了那幾個文件。）此時的test1.txt文件是可以提交的，它對應的是服務器的最新版本，即14版本（因爲這是svn將服務器最新版本14和A用戶修改內容合併後的結果）。但這是svn幫我們合併的，是不合法的文件。我們可以右鍵然後選擇，然後test1.txt就會變成14版本，A用戶的修改沒有了，A、B、服務器的test1.txt都成爲了14版本。如下圖：

接下來A用戶就可以再進行修改提交了。

總結

對於純文本文件因版本過時提交失敗的情況，我們可以選擇更新一下，然後打開”自己的修改和服務器最新版合併“後的文件（如上文發生衝突時的test1.txt文件），進行手動合併，處理好後選擇resolve然後提交。

對於非純文本文件因版本過時提交失敗時，我們只能犧牲一下自己，選擇，然後更新到服務器最新版本，再修改提交

例如，如果sally修改了一個文件sandwich.txt,而harry也剛剛修改了這個文件的相同位置並提交到服務器。那麼sally在做這個文件的 update操作的時候會得到三個額外的文件sandwich.txt.mine、sandwich.txt.r1、sandwich.txt.r2。並且在提交的時候會遭到服務器的拒絕，因爲這個文件的衝突問題還沒有得到解決。要解決這個衝突，可以選擇：
a.手工合併SVN衝突文件（檢查和修改文件中的衝突標誌）。
b.用一個臨時文件（三個中的一個）覆蓋你的工作文件。
c.運行svnrevert<filename>來放棄所有的修改。
一旦解決了你的衝突，需要通過命令svnresolved讓subversion知道並刪除三個臨時文件。這時纔可以提交。
下面再說說手工合併SVN衝突。開始的時候讓人覺得害怕，但做一段時間之後，就覺得不那麼煩人了。
看看如下文本：
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<<.mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
GrilledChicken
>>>>>>>.r2
CreoleMustard一連串的大於、小於、等於號是SVN衝突標記，這些數據得全部刪除纔可以提交。其中,
<<<<<<<.mine
Salami
Mortadella
Prosciutto
=======是你在衝突區裏面做的修改。
Sauerkraut
GrilledChicken
>>>>>>>.r2
是別人在衝突區做的修改。
在SVN衝突區中，或許你需要和你的同事溝通來安排衝突區的文本內容，如果是程序代碼，你需要和同事商量一下，中間的這段代碼到底應該是什麼樣子的。
所有衝突區得到合理的解決之後，你就可以提交你的文件了。

版本衝突原因：

假設A、B兩個用戶都在版本號爲100的時候，更新了kingtuns.txt這個文件，A用戶在修改完成之後提交kingtuns.txt到服務器，這個時候提交成功，這個時候kingtuns.txt文件的版本號已經變成101了。同時B用戶在版本號爲100的kingtuns.txt文件上作修改，修改完成之後提交到服務器時，由於不是在當前最新的101版本上作的修改，所以導致提交失敗。

版本衝突現象：

衝突發生時，subversion會在當前工作目錄中保存所有的目標文件版本[上次更新版本、當前獲取的版本(即別人提交的版本)、自己更新的版本、目標文件]。

假設文件名是kingtuns.txt

對應的文件名分別是：

kingtuns.txt.r101

kingtuns.txt.r102

kingtuns.txt.mine

kingtuns.txt。同時在目標文件中標記來自不同用戶的更改。

版本衝突解決：

場景：

1、現在A、B兩個用戶都更新kingtuns.txt文件到本地。