svn合併源和目標問題

Question

我正在使用SVN合併（兩種不同的樹）將樹幹合併到功能分支。

我選擇來源爲軀幹和目標爲featurebranch並從featurebranch本地工作區（黃金，精確複製的內容是在SVN）這樣做。

我在featurebranch中有一個新文件file1.xml，它不在trunk中。合併時，我得到一個樹衝突說合並試圖添加新文件，但它已經在本地。

我的問題是，爲什麼當我的源是沒有這個文件幹線合併甚至擔心在功能分支中的新文件。

我想在簽入之前確保合併正確發生。任何幫助，高度讚賞。

Answer 1

注：當你的分公司不能直接從主幹創建這個答案才適用。當從主幹分支，看到@Ben

合併的答案兩個不同的樹是被解讀爲DIFF和應用。如果你想把分支和樹幹放在同一層，你需要在分支和樹幹之間進行差異化，並將它應用到分支（基本上是你的工作副本）。這意味着，source =你的分支和target = trunk。

實施例：

svn merge https://svn/repo/branch https://svn/repo/trunk c:\svn\branch 

此命令將採取分支和軀幹之間的diff和應用的差異來工作副本分支。 （分支工作副本現在將與主幹一樣）

如果要將在trunk中完成的更改應用於分支（並且它是無基本合併），則需要指定要合併的修訂的範圍。

一個例子：

svn merge -r 10:HEAD https://svn/repo/trunk c:\svn\branch 

這將需要HEAD版本和軀幹的修訂10之間的差異並應用到分支。基本上應用這兩個修訂之間所做的更改。我懷疑這是你想要做的。

我建議你閱讀http://svnbook.red-bean.com/en/1.8/svn.branchmerge.advanced.html和命令行做合併。 TortoiseSVN合併對話是一團糟。

Answer 2

通過使用「兩種不同的樹」合併而不是簡單的「正常」合併，您正在使事情變得複雜。

你通過使用「兩種不同的樹」告訴SVN的是「採取所需的變化以獲取trunk並將其更改爲我的分支，並將這些更改應用於我的工作副本」。這不是你想要的，因爲這樣你就可以撤消主幹上的任何更改，然後重做所有分支更改。

與之相反，我認爲，在相反的情況下，「撤消我的分支上的所有更改，並在主幹上執行所有更改，以使我的工作副本與主幹匹配」。

如果我明白了，你真正想要的是「從我分支以來發生的所有幹線變化，並將它們應用到我的工作副本」。爲此，您需要將主幹合併到您的工作副本。您的分支的URL根本不會出現在合併命令中。這是SVN book中記錄的第一種合併形式。

Answer 3

你沒有給我們太多有關正在發生的事情的信息。如果您的方案中有更詳細的信息，以及您正在收到的錯誤消息，您將很高興。你有沒有做一個新的結賬？你用什麼命令來進行合併？你有什麼版本的Subversion客戶端和服務器？

否則，我們沒有太多的辦法來確定您的問題。將主幹合併到來自主幹的功能分支中通常應該合併，沒有任何問題。

我有第一個問題是你如何創建你的分支。當你在Subversion中創建一個分支，你應該在URL形式使用svn copy創建：

$ svn copy --parent $REPO/trunk $REPO/branches/feature 

我見過人們分支通過創建通過svn mkdir一個分支，那麼他們想要的文件複製這個分支的，然後將所有這些文件添加到分支上。 Subversion無法對這些項目進行合併，因爲它不知道它們的共享歷史記錄。對於Subversion來說，這些包含完全不同的文件。他們可能有相同的名稱和相似的內容，但它們是不同的文件。合併只是無效。

• 那麼，您是否以這種方式創建了分支？如果是這樣，你做得很好。

• 第二個問題：你是否將你的功能分支直接關閉後備箱？這不是必需條件，但如果要合併的分支不在要合併的分支中，則合併會更清晰。

• 第三個問題：您的功能分支是乾淨的結帳。 svn status --no-ignore告訴你什麼？你已經完成了svn update嗎？確保您的工作副本清潔可爲您節省很多麻煩。事實上，如果可能的話，我建議開發人員只做一次全新的結帳。

• 是你的服務器Subversion版本和你的客戶端Subversion 1.6或更高版本。合併跟蹤在版本1.5中增加了，但是這是一種惹人注目的事情。客戶端和服務器都應該至少爲1.6版本。 （目前的版本是1.8，版本1.9幾乎已經準備好發佈，所以1.6版本相當老舊）。

如果所有這些都是真的，合併應該非常簡單。你檢查出功能分支。然後，您將中繼合併到功能分支中。

$ svn co $REPO/branches/feature 
$ cd feature 
$ svn merge $REPO/trunk 

顛覆合併通常是三方面的事情。您將中繼線上的內容與功能分支上的內容進行了比較，和這兩個版本的最後一個共同祖先看起來是什麼樣子。通過在分支發生之前查看原始文件，Subversion可以知道發生了哪些分支，以及它是否應該被視爲合併的一部分。

事情在Subversion合併中有一些技巧，因爲還檢查了目錄更改。

在你的情況下，我能想象這樣的事情：

• 在原來的最後的共同祖先目錄，該文件在那裏。
• 在主幹中，文件已被刪除。
• 也有人從功能分支刪除，但隨後加回。

現在，Subversion會合並。最後一個共同的祖先擁有該文件。 Subversion查看樹幹，並看到該文件已被刪除。 Subversion查看分支，並看到該文件已被添加。

所以，Subversion看到了衝突。自從最後一個共同的祖先以來，它被添加到特徵分支上，但它也被從主幹中刪除。它應該做什麼？它不能簡單地刪除該文件，因爲它已添加到功能分支中。由於主幹和特徵分支發生了變化，因此發生了衝突。

如果您的工作副本中碰巧有一個不在Subversion中的文件，也會發生這種情況。 （就像數據文件一樣），並且像這樣的文件在主幹上被刪除。 Subversion想要刪除文件，但不能。這就是爲什麼開始清理你正在合併的分支是非常重要的。

可能還有其他原因，你也得到了這個。這很難說。在功能分支上進行乾淨的結帳。確保svn status -no-ignore什麼都不返回。確保您的工作副本完全保持最新狀態。做一個svn up就可以了。

然後，如果您收到錯誤消息，請提供完整的錯誤消息。檢查你的箱子，看看它的樣子。也針對您的特性分支的工作副本運行以下兩個命令：

$ svn mergeinfo --show-revs eligible $REPO/trunk 
$ svn mergeinfo --show-revs merged $REPO/trunk 

首先會告訴你，有資格被合併主幹的修訂。第二個將顯示以前合併的版本。

然後，查看這些更改的日誌，看看是否可以看到任何問題。有時我會在樹幹和分支上看到bug修復。這是兩個單獨的版本，但修復了相同的問題，因此修復此錯誤的主幹版本不應合併到分支中。您可以執行svn merge --record-only -c $rev將這些修訂合併到您的功能分支中，因此Subversion不會再嘗試合併它們。