我有一個在顛覆控制下的目錄。我只是爲了測試合併的東西而創建了一個分支。我拿了一個文件，把trunk中的第X行修改爲「abc」，並在其分支中將同一行X修改爲「def」。SVN合併問題
然後，從分支工作目錄我所做的：
svn merge branchURL trunkURL .
它更新了該行號的內容爲「ABC」的文件，即它並沒有給我在同一行號衝突因爲svn update會給我，如果我在同一個工作目錄中完成它並且有人在存儲庫中提交了「def」。
那麼svn merge只是在合併時替換內容而不會帶來任何衝突？
如果是這樣的話，當不能以某種方式合併以保持樹幹和分支的變化時，將主程序分支出主幹的非常有用。
你一定要明白什麼
svn merge branchUrl trunkUrl branchWorkingCopy
其實呢，是嗎？
這裏有一個翻譯：
找出一套必要作出branchUrl等同於那些trunkUrl的內容變化。現在在branchWorkingCopy上執行這些更改。
您不會因此合併任何衝突。但是，當您檢入branchWorkingCopy時，您將使您的分支與您的主幹相同，這幾乎肯定不是您想要的。
如果你只是想選擇的變化從幹線複製到分支，你需要告訴Subversion 這變化要複製並使用不同的形式合併命令：
svn merge -r100:103 trunkUrl branchWorkingCopy
這意味着：確定在trunk上從r100到r103所需的一組更改。在工作副本（分支）上執行這些更改。請注意，此「一組更改」將不包含r100所做的更改，因爲這些更改是由從r99到r100所需的一組更改捕獲的。 Subversion版本範圍爲，開放時間爲。
另外，如果你還沒有，請考慮閱讀fine manual。
所以做了svn合併只是取代 的內容，同時合併和不 帶來什麼衝突？
那麼，沒有。我無法真正指出你做錯了什麼，但合併標誌衝突與更新相同。
我可能會丟失一些東西，但是當我使用svn merge時，如果我希望它正常工作，我總是必須獲得修訂號。
所以，如果你在版本100支（或最後合併），樹幹目前爲200，和你想從主幹的修改合併到分支，然後在該分支的工作目錄，你做的事：
svn merge -r 100:200 trunkURL
然後我想你會看到一個衝突，你解決並檢查。你在幹線工作目錄中做類似的事情，從分支合併到幹線。
不帶-r的svn合併比較您指定的兩個位置，並將該diff應用於工作目錄。所以我推測發生了什麼事情就是沒有衝突，因爲你的工作目錄和分支的頭相匹配。因此，分支頭部和幹線頭部之間的差異可以毫無問題地應用於您的工作目錄。這不是你想要做的：它所做的只是改變你的工作目錄以匹配主幹。嘗試在分支上進行另一次更改，檢入並重復該過程。如果合併解除了這個改變（因爲它不在主幹上），那麼我對這種svn合併的形式是正確的，但正如我所說我沒有使用它。
[編輯：之前SVN版本1.5 ...]
工作目錄和分支機構不在SVN同樣的事情，和惱人的，因爲它是你必須考慮的差異。 SVN需要更多的信息來做你想要的分支合併，而不是進行更新或簽入，因爲afaik並不會自動考慮分支發生的位置，它總是佔用工作目錄的檢出位置。我確信有一個原因，我只是不知道它是什麼，可能是因爲svn副本比分支更多。
[編輯...但按照Joshua McKinnon對此答案的評論，從1.5開始，svn支持正確的分支合併，它可以自動執行所需的操作。指定要合併的URL，然後在合併到的任何工作目錄中運行該命令。所以在這種情況下，嘗試
svn merge trunkURL
，你應該看到的衝突。您可能必須先恢復工作目錄。]
直到顛覆1.5，我相信這一直是必要的。現在，來自目標workspce的直接'svn merge sourceURL'會將所有未記錄的修訂合併到subversion的元數據中。 – 2009-02-21 03:28:28
所以你1）分支2）修改後的行X到主幹上的「abc」3）切換到分支4）修改後的行X到分支上的「def」5）合併？在將其修改爲「abc」之前，X行的內容是什麼？ – 2009-02-21 23:45:45
我想在我的辦公室b/w我的客戶端svn和服務器svn會有一個版本差異，因爲我記得最近我將svn版本升級到了1.5版本，並且在回購版存在的服務器上沒有發生這種情況。所以我沒有得到衝突的事實可能是版本差異的結果。 – ashishsony 2009-02-22 12:53:34