1. 程式人生 > >SVN更新或提交時出現衝突該如何解決

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來放棄所有的修改。 一旦解決了你的衝突,需要通過命令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時每次都是先提交,後更新。每天早上開啟後,首先要從版本庫獲取最新版本。每天下班前必須將已經編輯過的文件都提交到版本庫。