解決版本衝突的命令。在衝突解決之後，需要使用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檔案），進行手動合併，處理好後選擇resolve然後提交。
例如，如果sally修改了乙個檔案sandwich.txt,而harry也剛剛修改了這個檔案的相同位置並提交到伺服器。那麼sally在做這個檔案的update操作的時候會得到三個額外的檔案sandwich.txt.mine、sandwich.txt.r1、sandwich.txt.r2。並且在提交的時候會遭到伺服器的拒絕，因為這個檔案的衝突問題還沒有得到解決。要解決這個衝突，可以選擇：
a.手工合併svn衝突檔案（檢查和修改檔案中的衝突標誌）。
b.用乙個臨時檔案（三個中的乙個）覆蓋你的工作檔案。
c.執行svnrevert來放棄所有的修改。
一旦解決了你的衝突，需要通過命令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檔案到本地。
2、文件中原始檔案內容如下：
3、a使用者修改檔案，新增內容「a使用者修改內容」完成後提交到伺服器
4、b使用者修改檔案，新增內容「b使用者修改內容」完成後提交到伺服器
b使用者提交更新至伺服器時提示如下：
b使用者將檔案提交至伺服器時，提示版本過期：首先應該從版本庫更新版本，然後去解決衝突，衝突解決後要執行svn resolved（解決），然後在簽入到版本庫。在衝突解決之後，需要使用svn resolved（解決）來告訴subversion衝突解決，這樣才能提交更新。
解決衝突有三種選擇：
a、放棄自己的更新，使用svn revert（回滾），然後提交。在這種方式下不需要使用svn resolved（解決）
b、放棄自己的更新，使用別人的更新。使用最新獲取的版本覆蓋目標檔案，執行resolved filename並提交(選擇檔案—右鍵—解決)。
c、手動解決：衝突發生時，通過和其他使用者溝通之後，手動更新目標檔案。然後執行resolved filename來解除衝突，最後提交。
解決步驟如下：
1、 在當前目錄下執行「update」（更新）操作
2、 在衝突的檔案上（選中檔案--右鍵選單—tortoisesvn—edit conflicts（解決衝突）），出現如下視窗
theirs視窗為伺服器上當前最新版本
mine視窗為本地修改後的版本
merged視窗為合併後的檔案內容顯示
3、 如果要使用伺服器版本，在theirs視窗選中差異內容，右鍵，選擇use this text block（使用這段文字塊）。
同理如果要使用本地版本，在協商後，在mine視窗右鍵，選擇use this text block（使用這段文字塊）。
4、 修改完成後，儲存kingtuns.txt檔案內容。
5、 在b使用者的衝突目錄下，選中檔案--右鍵選單—tortoisesvn—resolved（解決）。會列出衝突的檔案列表，如果確認已經解決，點ok。
6、 衝突解決
7、提交解決衝突後的檔案。
如何降低衝突解決的複雜度：
1、當文件編輯完成後，盡快提交，頻繁的提交/更新可以降低在衝突發生的概率，以及發生時解決衝突的複雜度。
2、在提交時，寫上明確的message，方便以後查詢使用者更新的原因，畢竟隨著時間的推移，對當初更新的原因有可能會遺忘
3、養成良好的使用習慣，使用svn時每次都是先提交，後更新。每天早上開啟後，首先要從版本庫獲取最新版本。每天下班前必須將已經編輯過的文件都提交到版本庫。
svn版本衝突問題
在實際專案開發中，如果2個人同時修改某個檔案就會產生版本衝突問題 比如程式設計師a,b同時修改檔案hello.txt，a在10點提交了一次，但是b不知道a已經提交了，他的版本還是a提交之前的版本，所以他在10點30也提交自己的，這時候就會發生版本衝突。如何解決這個問題 1.合理安排專案開發時間 a在...
SVN版本衝突解決詳解
版本衝突原因 假設 a b兩個使用者都在版本號為 100的時候，更新了 kingtuns.txt 這個檔案，a使用者在修改完成之後提交 kingtuns.txt 到伺服器，這個時候提交成功，這個時候 kingtuns.txt 檔案的版本號已經變成 101了。同時 b使用者在版本號為 100的 kin...
SVN版本衝突解決詳解
版本衝突原因 假設a b兩個使用者都在版本號為100的時候，更新了kingtuns.txt這個檔案，a使用者在修改完成之後提交kingtuns.txt到伺服器，這個時候提交成功，這個時候kingtuns.txt檔案的版本號已經變成101了。同時b使用者在版本號為100的kingtuns.txt檔案上...