SVN出現歎號檔案衝突解決辦法

SVN出現歎號檔案衝突解決辦法 此方法是我在網上看到的，當時自己也遇到SVN檔案衝突，看了後感覺還不錯 ，所以收藏一下與大家分享 如下： 解決版本衝突的命令。在衝突解決之後，需要使用svn resolved來告訴subversion衝突解決，這樣才能提交更新。衝突發生時，subversion會在Work Copy中儲存所有的目標檔案版本（上次更新版本、當前擷取的版本，即別人提交的版本、自己更新的版本、目標檔案。假設檔案名稱是sandwich.txt，對應的檔案名稱分別是：sandwich.txt.r1、sandwich.txt.r2、sandwich.txt.mine、sandwich.txt）。同時在目標檔案中標記來自不同使用者的更改。 解決衝突的辦法： - 手動解決：衝突發生時，通過和其他使用者溝通之後，手動更新目標檔案。然後執行svn resolved filename來解除衝突，最後提交。 - 放棄自己的更新，使用別人的更新。使用最新擷取的版本覆蓋目標檔案，執行svn resolved filename並提交。 - 放棄自己的更新，使用svn revert，然後提交。在這種方式下不需要使用svn resolved。 對於svn resolved命令需要非常小心，必須是非常確定衝突已經解決才能使用。否則，會導致Subversion以為衝突解決，而使程式碼程式庫不正確。 解決衝突詳細文檔: http://svnbook.subversion.org.cn/1.2/svn.tour.cycle.html#svn.tour.cycle.resolve 解決衝突（合并別人的修改） 我們可以使用svn status -u來預測衝突，當你運行svn update一些有趣的事情發生了： $ svn update U INSTALL G README C bar.c Updated to revision 46. U和G沒必要關心，檔案乾淨的接受了版本庫的變化，檔案標示為U表明本地沒有修改，檔案已經根據版本庫更新。G標示合并，標示本地已經修改過，與版本庫沒有重迭的地方，已經合并。 但是C表示衝突，說明伺服器上的改動同你的改動衝突了，你需要自己手工去解決。 當衝突發生了，有三件事可以協助你注意到這種情況和解決問題： Subversion列印C標記，並且標記這個檔案已衝突。 如果Subversion認為這個檔案是可合并的，它會置入衝突標記—特殊的橫線分開衝突的“兩面”—在檔案裡可視化的描述重疊的部分（Subversion使用svn:mime-type屬性來決定一個檔案是否可以使用內容相關的，以行為基礎合并，更多資訊可以看“svn:mime-type”一節）。 對於每一個衝突的檔案，Subversion放置三個額外的未版本化檔案到你的工作拷貝： filename.mine 你更新前的檔案，沒有衝突標誌，只是你最新更改的內容。（如果Subversion認為這個檔案不可以合并，.mine檔案不會建立，因為它和工作檔案相同。） filename.rOLDREV 這是你的做更新操作以前的BASE版本檔案，就是你在上次更新之後未作更改的版本。 filename.rNEWREV 這是你的Subversion用戶端從伺服器剛剛收到的版本，這個檔案對應版本庫的HEAD版本。 這裡OLDREV是你的.svn目錄中的修訂版本號碼，NEWREV是版本庫中HEAD的版本號碼。 舉一個例子，Sally修改了sandwich.txt，Harry剛剛改變了他的本地拷貝中的這個檔案並且提交到伺服器，Sally在提交之前更新它的工作拷貝得到了衝突： $ svn update C sandwich.txt Updated to revision 2. $ ls -1 sandwich.txt sandwich.txt.mine sandwich.txt.r1 sandwich.txt.r2 在這種情況下，Subversion不會允許你提交sandwich.txt，直到你的三個臨時檔案被刪掉。 $ svn commit --message "Add a few more things" svn: Commit failed (details follow): svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict 如果你遇到衝突，三件事你可以選擇： “手動”合并衝突文本（檢查和修改檔案中的衝突標誌）。 用某一個臨時檔案覆蓋你的工作檔案。 運行svn revert 來放棄所有的修改。 一旦你解決了衝突，你需要通過命令svn resolved讓Subversion知道，這樣就會刪除三個臨時檔案，Subversion就不會認為這個檔案是在衝突狀態了。[5] $ svn resolved sandwich.txt Resolved conflicted state of 'sandwich.txt' 手工合并衝突 第一次嘗試解決衝突讓人感覺很害怕，但經過一點訓練，它簡單的像是騎著車子下坡。 這裡一個簡單的例子，由於不良的交流，你和同事Sally，同時編輯了sandwich.txt。Sally提交了修改，當你準備更新你的版本，衝突發生了，我們不得不去修改sandwich.txt來解決這個問題。首先，看一下這個檔案： $ cat sandwich.txt Top piece of bread Mayonnaise Lettuce Tomato Provolone <<<<<<< .mine Salami Mortadella Prosciutto ======= Sauerkraut Grilled Chicken >>>>>>> .r2 Creole Mustard Bottom piece of bread 小於符號、等號和大於符號串是衝突標記，並不是衝突的資料，你一定要確定這些內容在下次提交之前得到刪除，前兩組標誌中間的內容是你在衝突區所做的修改： <<<<<<< .mine Salami Mortadella Prosciutto ======= 後兩組之間的是Sally提交的修改衝突： ======= Sauerkraut Grilled Chicken >>>>>>> .r2 通常你並不希望只是刪除衝突標誌和Sally的修改—當她收到三明治時，會非常的吃驚。所以你應該走到她的辦公室或是拿起電話告訴Sally，你沒辦法從從意大利熟食店得到想要的泡菜。[6]一旦你們確認了提交內容後，修改檔案並且刪除衝突標誌。 Top piece of bread Mayonnaise Lettuce Tomato Provolone Salami Mortadella Prosciutto Creole Mustard Bottom piece of bread 現在運行svn resolved，你已經準備好提交了： $ svn resolved sandwich.txt $ svn commit -m "Go ahead and use my sandwich, discarding Sally's edits." 記住，如果你修改衝突時感到混亂，你可以參考subversion產生的三個檔案—包括你未作更新的檔案。你也可以使用第三方的合并工具檢驗這三個檔案。 拷貝覆蓋你的工作檔案 如果你只是希望取消你的修改，你可以僅僅拷貝Subversion為你產生的檔案替換你的工作拷貝： $ svn update C sandwich.txt Updated to revision 2. $ ls sandwich.* sandwich.txt sandwich.txt.mine sandwich.txt.r2 sandwich.txt.r1 $ cp sandwich.txt.r2 sandwich.txt $ svn resolved sandwich.txt 下註：使用svn revert 如果你得到衝突，經過檢查你決定取消自己的修改並且重新編輯，你可以恢複你的修改： $ svn revert sandwich.txt Reverted 'sandwich.txt' $ ls sandwich.* sandwich.txt 注意，當你恢複一個衝突的檔案時，不需要再運行svn resolved。 現在我們準備好提交修改了，注意svn resolved不像我們本章學過的其他命令一樣需要參數，在任何你認為解決了衝突的時候，只需要小心運行svn resolved，—一旦刪除了臨時檔案，Subversion會讓你提交這檔案，即使檔案中還存在衝突標記。 提交你得修改 最後。你的修改結束了，你合并了伺服器上所有的修改，你準備好提交修改到版本庫。 svn commit命令發送所有的修改到版本庫，當你提交修改時，你需要提供一些描述修改的日誌資訊，你的資訊會附到這個修訂版本上，如果資訊很簡短，你可以在命令列中使用--message（-m）選項： $ svn commit --message "Corrected number of cheese slices." Sending sandwich.txt Transmitting file data . Committed revision 3. 然而，如果你把寫日誌資訊當作工作的一部分，你也許會希望通過告訴Subversion一個檔案名稱得到日誌資訊，使用--file選項： $ svn commit --file logmsg Sending sandwich.txt Transmitting file data . Committed revision 4. 如果你沒有指定--message或者--file選項，Subversion會自動地啟動你最喜歡的編輯器（見“config”一節的editor-cmd部分）來編輯日誌資訊。 提示 如果你使用編輯器撰寫日誌資訊時希望取消提交，你可以直接關掉編輯器，不要儲存，如果你已經做過儲存，只要簡單的刪掉所有的文本並再次儲存。 $ svn commit Waiting for Emacs...Done Log message unchanged or not specified a)bort, c)ontinue, e)dit a $ 版本庫不知道也不關心你的修改作為一個整體是否有意義，它只檢查是否有其他人修改了同一個檔案，如果別人已經這樣做了，你的整個提交會失敗，並且提示你一個或多個檔案已經過時了： $ svn commit --message "Add another rule" Sending rules.txt svn: Commit failed (details follow): svn: Out of date: 'rules.txt' in transaction 'g' 此刻，你需要運行svn update來處理所有的合并和衝突，然後再嘗試提交。 我們已經覆蓋了Subversion基本的工作周期，還有許多其它特性可以管理你得版本庫和工作拷貝，但是只使用前面介紹的命令你就可以很輕鬆的工作了。 [3] 當然沒有任何東西是在版本庫裡被刪除了—只是在版本庫的HEAD裡消失了，你可以通過檢出（或者更新你的工作拷貝）你做出刪除操作的前一個修訂版本來找回所有的東西。 [4] Subversion使用內建區別引擎，預設情況下輸出為統一區別格式。如果你期望不同的輸出格式，你可以使用--diff-cmd指定外置的區別程式，並且通過--extensions傳遞其他參數，舉個例子，察看本地檔案foo.c的區別，同時忽略空格修改，你可以運行svn diff --diff-cmd /usr/bin/diff --extensions '-bc' foo.c。 [5] 你也可以手工的刪除這三個臨時檔案，但是當Subversion會給你做時你會自己去做嗎。我們是這樣想的。 [6] 如果你向他們詢問，他們非常有理由把你帶到城外的鐵軌上。 如何降低衝突解決的複雜度: - 當工作完成之後（即編寫完程式，單元測試通過）儘快的提交，頻繁的提交/更新可以降低在衝突發生的機率，以及發生時解決衝突的複雜度。 - 如果衝突頻繁發生，就有必要找出原因了。 - 在提交時，書寫明確的message。方便以後的尋找更新的原因，畢竟隨著時光流逝，記憶也會變得模糊。