本文向你們介紹一下SVN衝突問題中的SVN文件衝突和樹衝突問題,在這裏和你們分享一下,但願經過本文的學習你們對SVN衝突問題有清晰的認識。
本節和你們一塊兒學習一下SVN文件衝突和樹衝突,主要包括SVN文件衝突
和樹衝突如何出現,以及怎樣解決這些衝突,但願經過本文的學習你們可以掌握住這些方法。
解決衝突
偶爾,當你從版本庫更新、合併文件時,或者切換工做副本至一個不一樣的URL時你會遇到衝突。有兩種衝突:
SVN文件衝突
當兩名(或更多)開發人員修改了同一個文件中相鄰或相同的行時就會發生文件衝突。
SVN樹衝突
當一名開發人員移動、重命名、刪除一個文件或文件夾,而另外一名開發人員也對它們進行了移動、重命名、刪除或者僅僅是修改時就會發生樹衝突。
SVN文件衝突
當兩名或更多開發人員修改了同一個文件中相鄰或相同的行時就會發生文件衝突。因爲Subversion不知道你的項目的具體狀況,它把解決衝突的工做留給了開發人員。一旦出現衝突,你就應該打開有問題的文件,查找以字符串<<<<<<<開頭的行。有衝突的區域用以下的方式標記:
<<<<<<<文件名你的修改=======合併自版本庫中的代碼>>>>>>>版本
對於每一個衝突的文件Subversion在你的目錄下放置了三個文件:
文件名.ext.mine
這是你的文件,在你更新你的工做副本以前存在於你的的工做副本中——也就是說,沒有衝突標誌。這個文件除了你的最新修改外沒有別的東西。
文件名.ext.r舊版本
這是在你更新你的工做副本以前的基礎版本(BASErevision)文件。也就是說,它是在你作最後修改以前所檢出的文件。
文件名.ext.r新版本
這個文件是當你更新你的工做副本時,你的Subversion客戶端從服務器接收到的。這個文件對應於版本庫中的最新版本。
你能夠經過TortoiseSVN→編輯衝突運行外部合併工具/衝突編輯器,或者你可使用任何別的編輯器手動解決衝突。你須要衝定哪些代碼是須要的,作一些必要的修改而後保存。
而後,執行命令TortoiseSVN→已解決並提交人的修改到版本庫。須要注意的是已解決命令並非真正的解決了衝突,它只是刪除了filename.ext.mine和filename.ext.r*兩個文件,容許你提交修改。
若是你有二進制SVN文件衝突,Subversion不會試圖合併文件。本地文件保持不變(徹底是你最後修改時的樣子),但你會看到filename.ext.r*文件。若是你要撤消你的修改,保留版本庫中的版本,請使用還原(Revert)命令。若是你要保持你的版本覆蓋版本庫中的版本,使用已解決命令,而後提交你的版本。
你能夠右擊父文件夾,選擇TortoiseSVN→已解決...,使用「已解決」命令來解決多個文件。這個操做會出現一個對話框,列出文件夾下全部有衝突的文件,你能夠選擇將哪些標記成已解決。
樹衝突
當一名開發人員移動、重命名、刪除一個文件或文件夾,而另外一名開發人員也對它們進行了移動、重命名、刪除或者僅僅是修改時就會發生樹衝突。有不少種不一樣的情形能夠致使樹衝突,並且不一樣的情形須要不一樣的步驟來解決衝突。
當一個文件經過Subversion在本機刪除後,文件也從本機文件系統中刪除。所以即便它是樹衝突的一部分,卻既不能顯示衝突的疊加圖標也不能經過右鍵單擊來解決衝突。使用檢查修改對話框來得到編輯衝突選項。
TortoiseSVN可以協助找到合併更改的正確位置,可是須要做一些額外的工做來整理衝突。請牢記:當進行一次更新操做後,工做副本的基礎文件將會包括每個項目在執行更新操做時版本庫中的版本。若是你在進行更新後再撤銷更改,工做副本將返回到版本庫的狀態,而不是你開始進行更改前的狀態。
本地刪除,當更新時有更改進入開發人員A修改Foo.c並將其提交至版本庫中
開發人員B同時在他的工做副本中將文件Foo.c更名爲Bar.c,或者僅僅是刪除了Foo.c或它的父文件夾。
更新開發人員B的工做副本會致使樹衝突:
在工做副本中,Foo.c被刪除了,可是被標記爲樹衝突。
若是衝突是因爲更改文件名引發的而不是刪除文件引發的,那麼Bar.c被標記爲添加,可是其中卻不包括開發人員A修改的內容。
開發人員B如今必須作出選擇是否保留開發人員A的更改。在更改文件名的案例中,他能夠將Foo.c的更改合併到更名後的文件Bar.c中去。對於刪除文件或文件夾的案例中,他能夠選擇保留包含開發人員A更改內容的項目並放棄刪除操做。或什麼也不作而直接將衝突標記爲已解決,那樣他實際上丟棄了開發人員A的更改。
若是TortoiseSVN可以找到被更名爲Bar.c的原始文件,衝突編輯對話框將能夠合併更改。這取決於在什麼地方調用更新操做,它也許不能找到原始文件。
本地更改,當更新時有刪除進入開發人員A將文件Foo.c更名爲Bar.c並將其提交至版本庫中。
開發人員B在他的工做副本中修改文件Foo.c。或者在一個文件夾更名的案例中...
開發人員A將父文件夾FooFolder更名爲BarFolder並將其提交至版本庫中。
開發人員B在他的工做副本中修改文件Foo.c。
更新開發人員B的工做副本會致使樹衝突。對於一個簡單的SVN文件衝突:
Bar.c被看成一個正常文件添加到工做副本中。
Foo.c被標記爲添加(包括其歷史記錄)而且產生樹衝突。
對於一個文件夾衝突:
BarFolder被看成一個正常文件夾添加到工做副本中。
FooFolder被標記爲添加(包括其歷史記錄)而且產生樹衝突。
Foo.c被標記爲已修改。
開發人員B如今須要作出決定是否接受開發人員A做出的結構改變而且合併她的更改到新結構下適當的文件中,或者直接放棄開發人員A的更改並保留本地文件。
要合併她的本機更改到新佈局中,開發人員B必須先找出衝突的文件Foo.c通過更名/移動後在版本庫中的新文件名是什麼。可使用日誌對話框來完成這個任務。更改必需要手工合併,由於沒有辦法自動的或者簡單的完成此操做。一旦更改移植完畢,衝突的路徑就是多餘的而且能夠刪除。在此案例中,使用衝突編輯對話框中的刪除按鈕進行清理並將衝突標記爲已解決。
若是開發人員B認爲A的更改是錯誤的,那麼在衝突編輯對話框中她必須選擇保留按鈕。這樣就會標記衝突的文件/文件夾爲已解決,可是須要手工刪除開發人員A的更改。又是經過日誌對話框幫助追蹤哪些文件移動了。請期待下節SVN文件衝突和樹衝突問題講解。
【編輯推薦】
- 揭開SVN衝突神祕面紗
- SVN衝突解決方法大全
- SVN衝突解決方法名師介紹
- SVN衝突問題專家詳解
- SVN服務器安裝指導手冊
- http://developer.51cto.com/art/201005/202293.htm