2013-05-13 71 views
3

我正在使用一個代碼庫(歷史記錄)已經通過手工合併而不是通過svn merge。我試圖通過證明對大家有用的合併是如何改變這種狀況 - 但是當我做一個預演,我得到這個:svn merge --dry-run顯示svn區別

$ svn merge [[Repo URL]] . -c 21355,21358,21364,21370,21371,21373 --dry-run 
--- Merging r21355 into '.': 
U [[File 1]] 
--- Merging r21355 into '[[dir]]': 
U [[dir]]/[[File 2]] 
U [[dir]]/[[File 3]] 
--- Merging r21358 into '[[dir]]': 
U [[dir]]/[[File 4]] 
--- Merging r21364 into '[[dir]]': 
U [[dir]]/[[File 2]] 
C [[dir]]/[[File 4]]  
--- Merging r21370 into '[[dir]]': 
U [[dir]]/[[File 5]] 
--- Merging r21371 into '[[dir]]': 
U [[dir]]/[[File 5]] 
--- Merging r21373 into '[[dir]]': 
C [[dir]]/[[File 5]] 
U [[dir]]/[[File 6]] 
Summary of conflicts: 
    Text conflicts: 2 

我有兩個文件(被列爲4和5,分別),即在一次合併中倖存下來只會與最後一次合併發生衝突。我試圖弄清楚現在是什麼衝突,看看我能否解決它。如果我可以強迫svn吐出兩個衝突變化的差異,我會喜歡它。

我檢查了剛剛最窄目錄的一個新的工作副本中,當我跑不空轉合併,我得到:

--- Merging r21355 into '.': 
U [[File 3]] 
--- Merging r21358 into '.': 
U [[File 4]] 
--- Merging r21364 into '.': 
G [[File 4]] 
--- Merging r21370 into '.': 
U [[File 5]] 
--- Merging r21371 into '.': 
G [[File 5]] 
--- Merging r21373 into '.': 
G [[File 5]] 

(文件1,2,6駐留在別處)

所以,現在我特別困惑 - 幹運行報告衝突,但是當合並實際運行時,它是成功的?這是預期的行爲?我承認我不是SVN巫師,但我很困惑。

+0

我可以用兩個修訂版重現此問題。 Rev 7增加了一個文件,Rev 8改變了文件。命令'svn merge -r6:8'和'svn merge -c7,8'產生相同的結果。但是,如果我添加「--dry-run」選項,則前者成功,後者失敗。聽起來像是SVN 1.7中的一個bug。 – nosid 2013-05-13 20:03:32

+0

@nosid我正在運行1.6.3 – FrankieTheKneeMan 2013-05-13 20:46:10

回答

1

這是--dry-run的預期行爲,它不修改文件系統。

因爲您指定了單獨的修訂版,所以這些修訂版正在分開應用,一個接一個地。合併輸出中的G表示合併發生 - svn對已經有本地更改的文件進行了更改。

詳細:

  • r21358修改文件4.
  • 在一個正常的合併,文件4現在有局部變化和r21364合併這些變化在一起,因爲DIFF文件的當前狀態相匹配。
  • 在幹運行中,文件4沒有被r21358改變。該文件與下一版本r21364預期的不匹配,因此您會發生衝突。
  • r21373發生同樣的情況 - r21370或r21371修改了它適用的文件的相同部分。
  • r21371不會因此受到影響,因爲它影響文件5的另一部分而不是r21370。

一旦你經過了所有這些打嗝,你將能夠一次性合併所有這些,而無需指定個別修訂,這種幹運行和常規合併之間的區別將會發生遠。

+0

我認爲這在技術上發生了什麼,但我認爲這是一個錯誤,而不是預期的行爲。 [此問題](http://subversion.tigris.org/issues/show_bug.cgi?id=2584),標記爲已刪除並重新添加的文件已修復,似乎表明「merge - dry-run '應該像'merge'一樣正常運行,不需要改變任何文件。 '--dry-run'應該是一個工具,可以讓你在遇到它們之前檢查這些問題。 – FrankieTheKneeMan 2013-12-20 20:38:32