(摘自西西軟件園,原文連接http://www.cr173.com/html/46224_1.html)html
解決版本衝突的命令。在衝突解決以後,須要使用svnresolved來告訴subversion衝突解決,這樣才能提交更新。衝突發生時,subversion會在WorkCopy中保存全部的目標文件版本(上次更新版本、當前獲取的版本,即別人提交的版本、本身更新的版本、目標文件。git
開發人員都知道代碼管理工具是開發中一個必不可少的工具,這裏也不廢話詳細介紹了。無論你我的喜歡git仍是svn仍是其餘,但還有一大部分公司在使用svn作代碼管理工具。這裏詳細介紹下SVN提交文件時衝突問題的解決方式。服務器
假設A、B兩個用戶,他們分別從svn服務器中檢出了test1.txt文件,此時A、B、服務器三個地方的test1.txt的版本都是13(我測試環境的當前svn賦予的版本號)。A、B文件的內容以下圖(左A右B):svn
·工具
接下來,B用戶添加一句話並提交,內容以下:測試
此時B用戶和服務器的test1.txt的版本都變爲14,只有A用戶的test1.txt的版本還爲13。接下來A用戶添加一句「aa」,而後提交this
因爲A用戶是在13版本上作的修改,而服務器已是14版本了,因此會提交失敗:3d
接下來就是咱們要解決的問題了,解決方法分爲如下兩種方式。第一種方式:提交失敗後直接選擇revert,省去了解決衝突問題;第二種方式:提交失敗後選擇更新文件,這時會有衝突問題。詳細介紹以下:excel
第一種方式:htm
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.r1三、test1.text.r14將會消失。用戶A就能夠順利提交了。可是,若是test1.txt是一個非純文本文件,好比excel,這時的test1.txt將無法手動合併了,不得不放棄本身的修改。能夠在test1.txt上右鍵選擇消除掉test.txt.mine、test1.txt.r1三、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.r一、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。同時在目標文件中標記來自不一樣用戶的更改。
版本衝突解決:
場景:
一、如今A、B兩個用戶都更新kingtuns.txt文件到本地。
二、文檔中原始文件內容以下:
三、A用戶修改文件,添加內容「A用戶修改內容」完成後提交到服務器
四、B用戶修改文件,添加內容「B用戶修改內容」完成後提交到服務器
B用戶提交更新至服務器時提示以下:
B用戶將文件提交至服務器時,提示版本過時:首先應該從版本庫更新版本,而後去解決衝突,衝突解決後要執行svn resolved(解決),而後在簽入到版本庫。在衝突解決以後,須要使用svn resolved(解決)來告訴subversion衝突解決,這樣才能提交更新。
解決衝突有三種選擇:
A、放棄本身的更新,使用svn revert(回滾),而後提交。在這種方式下不須要使用svn resolved(解決)
B、放棄本身的更新,使用別人的更新。使用最新獲取的版本覆蓋目標文件,執行resolved filename並提交(選擇文件—右鍵—解決)。
C、手動解決:衝突發生時,經過和其餘用戶溝通以後,手動更新目標文件。而後執行resolved filename來解除衝突,最後提交。
解決步驟以下:
一、 在當前目錄下執行「update」(更新)操做
二、 在衝突的文件上(選中文件--右鍵菜單—TortoiseSVN—Edit conflicts(解決衝突)),出現以下窗口
Theirs窗口爲服務器上當前最新版本
Mine窗口爲本地修改後的版本
Merged窗口爲合併後的文件內容顯示
三、 若是要使用服務器版本,在Theirs窗口選中差別內容,右鍵,選擇Use this text block(使用這段文本塊)。
同理若是要使用本地版本,在協商後,在Mine窗口右鍵,選擇Use this text block(使用這段文本塊)。
四、 修改完成後,保存kingtuns.txt文件內容。
五、 在B用戶的衝突目錄下,選中文件--右鍵菜單—TortoiseSVN—Resolved(解決)。會列出衝突的文件列表,若是確認已經解決,點OK。
六、 衝突解決
七、提交解決衝突後的文件。
如何下降衝突解決的複雜度:
一、當文檔編輯完成後,儘快提交,頻繁的提交/更新能夠下降在衝突發生的機率,以及發生時解決衝突的複雜度。
二、在提交時,寫上明確的message,方便之後查找用戶更新的緣由,畢竟隨着時間的推移,對當初更新的緣由有可能會遺忘
三、養成良好的使用習慣,使用SVN時每次都是先提交,後更新。天天早上打開後,首先要從版本庫獲取最新版本。天天下班前必須將已經編輯過的文檔都提交到版本庫。