解決版本沖突的命令。在沖突解決之后,需要使用svnresolved來告訴subversion沖突解決,這樣才能提交更新。沖突發(fā)生時,subversion會在WorkCopy中保存所有的目標文件版本(上次更新版本、當前獲取的版本,即別人提交的版本、自己更新的版本、目標文件。
開發(fā)人員都知道代碼管理工具是開發(fā)中一個必不可少的工具,這里也不廢話詳細介紹了。不管你個人喜歡git還是svn還是其他,但還有一大部分公司在使用svn做代碼管理工具。這里詳細介紹下SVN提交文件時沖突問題的解決方式。
假設A、B兩個用戶,他們分別從svn服務器中檢出了test1.txt文件,此時A、B、服務器三個地方的test1.txt的版本都是13(我測試環(huán)境的當前svn賦予的版本號)。A、B文件的內容如下圖(左A右B):
·
接下來,B用戶添加一句話并提交,內容如下:
此時B用戶和服務器的test1.txt的版本都變?yōu)?4,只有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將沒法手動合并了,不得不放棄自己的修改?梢栽趖est1.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用戶就可以再進行修改提交了。
總結
對于純文本文件因版本過時提交失敗的情況,我們可以選擇更新一下,然后打開”自己的修改和服務器最新版合并“后的文件(如上文發(fā)生沖突時的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
=======是你在沖突區(qū)里面做的修改。
Sauerkraut
GrilledChicken
>>>>>>>.r2
是別人在沖突區(qū)做的修改。
在SVN沖突區(qū)中,或許你需要和你的同事溝通來安排沖突區(qū)的文本內容,如果是程序代碼,你需要和同事商量一下,中間的這段代碼到底應該是什么樣子的。
所有沖突區(qū)得到合理的解決之后,你就可以提交你的文件了。
版本沖突原因:
假設A、B兩個用戶都在版本號為100的時候,更新了kingtuns.txt這個文件,A用戶在修改完成之后提交kingtuns.txt到服務器,這個時候提交成功,這個時候kingtuns.txt文件的版本號已經變成101了。同時B用戶在版本號為100的kingtuns.txt文件上作修改,修改完成之后提交到服務器時,由于不是在當前最新的101版本上作的修改,所以導致提交失敗。
版本沖突現象:
沖突發(fā)生時,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用戶將文件提交至服務器時,提示版本過期:首先應該從版本庫更新版本,然后去解決沖突,沖突解決后要執(zhí)行svn resolved(解決),然后在簽入到版本庫。在沖突解決之后,需要使用svn resolved(解決)來告訴subversion沖突解決,這樣才能提交更新。
解決沖突有三種選擇:
A、放棄自己的更新,使用svn revert(回滾),然后提交。在這種方式下不需要使用svn resolved(解決)
B、放棄自己的更新,使用別人的更新。使用最新獲取的版本覆蓋目標文件,執(zhí)行resolved filename并提交(選擇文件—右鍵—解決)。
C、手動解決:沖突發(fā)生時,通過和其他用戶溝通之后,手動更新目標文件。然后執(zhí)行resolved filename來解除沖突,最后提交。
解決步驟如下:
1、 在當前目錄下執(zhí)行“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、當文檔編輯完成后,盡快提交,頻繁的提交/更新可以降低在沖突發(fā)生的概率,以及發(fā)生時解決沖突的復雜度。
2、在提交時,寫上明確的message,方便以后查找用戶更新的原因,畢竟隨著時間的推移,對當初更新的原因有可能會遺忘
3、養(yǎng)成良好的使用習慣,使用SVN時每次都是先提交,后更新。每天早上打開后,首先要從版本庫獲取最新版本。每天下班前必須將已經編輯過的文檔都提交到版本庫。