合併到分支時發生衝突刪除代碼中的一些更改

Question

我們最近創建了一個分支，其中包含爲特定客戶端定製的代碼版本。我們同時在兩個分支上工作，向主幹提交'通用'更改，然後將它們合併到分支。

最近，我們遇到了一個麻煩的情況。在trunk/bar.c我們有（其中包括）foo()功能。現在，在branch/bar.c該功能被刪除，因爲它沒有用處。在trunk中修改foo()時會出現問題。當我們將更改合併到分支（「合併修訂版本範圍」）時，TortoiseSVN「3-way合併」工具顯示衝突上的方法（這是令人討厭的，但我可以看到一些原因），但它也顯示整個很多其他變化在文件中 - 這似乎顯得空氣稀薄（看起來有點像，如果它想顯示所有變化之間的幹線和分支）。這使合併變得更加困難，因爲它充滿了一些不重要的舊變化。

這樣的情況發生在你身上嗎？你會提出什麼建議，特別是在合併時更容易發現重要差異？

作爲一個（希望）臨時解決方案，我將嘗試和刪除區域中的#ifdef，以便SVN會認爲代碼仍然存在，並且合併時間更長。 （不幸的是，這會讓代碼變得有些醜陋，並且在刪除更多功能時變得越來越醜）。

Answer 1

嗯，我不是SVN專家，但我可以建議您從提交中導出補丁你的第一個分支，並將補丁應用到第二個分支。

我想這幾乎是Mercurial的'hg transplant XXX'命令所做的。不過，我不知道是否存在任何SVN等價命令。

Answer 2

你可能要考慮

1. 你的提交是否足夠頻繁，
2. 無論你是合併正確的版本或版本範圍。

這聽起來像你沒有得到你想要的與你的修訂的粒度;也就是說，一個修訂包含許多變化。無論是或者你正在嘗試合併比你需要更廣泛的修訂版本。無論如何，如果你更經常提交，這可能會有所幫助。

對於這種特殊情況，您必須手動合併文件—，那麼您應該可以合併後續修訂，而不涉及foo()而無需任何干預。

Answer 3

如果更改了分支上已刪除的主幹上的功能，則可能會發生衝突，這很自然。

是的，對於「右手邊」，你會看到幹線和分支之間的所有變化。如果你仔細想想，這是唯一可以合理顯示的變化。 （至少，服務器上的1.4版本就是這種情況;具有更好合並跟蹤的更高版本可能會更加簡潔，但您需要有足夠的客戶端版本，我不確定。以升級......感嘆。）但是，顯示的分支更改應該全部自動標記爲合併未修改，除非它們與主幹中的更改發生衝突或以其他方式進行交互。

你不應該爲你看到的一系列變化感到驚訝。如果你是，那麼你要麼選擇了錯誤的版本，要麼就是誤解了合併過程的工作原理。