SVN想從主幹合併到分支無限期

Question

我的SVN回購協議是這樣的：

/trunk 
/branches/project1/trunk 
/branches/project1/branches 

我的目錄/分支機構/ PROJECT1 /行李箱/行李箱的一個分支。我對這個分支做了很多修改（新代碼，新增文件，刪除文件等）。我有時從分支合併到主幹，從主幹合併到分支。但是我的錯誤是在任何情況下總是使用「合併一系列修訂」。我最近才明白，「合併一系列修訂」應該用於從樹幹到分支的合併，「重新分支分支」用於從分支合併到樹幹。

所以今天，我嘗試用正確的方法合併來自分支的差異到主幹，並修復了很多衝突。但從那時起，當我從分支合併到主幹以及從主幹合併到分支時，SVN想要「更新」分支中一天添加的一些文件。除了增加轉速以外，更新不做任何事情。如果我嘗試合併2到3次，每次都會更新相同的文件（例如，僅增加轉數）。

有沒有辦法解決這個問題？或者我應該刪除我的分支，並創建一個新的，在同一條路徑？

的SVN版本是：

TortoiseSVN 1.6.16, Build 21511 - 32 Bit , 2011/06/01 19:00:35 
Subversion 1.6.17 

Answer 1

你這裏的問題是您的工作流程。分支機構不是按照您使用它們的方式設計的。您可以將更改合併到分支源代碼的分支中（在您的示例中爲/trunk），但是一旦將分支更改合併回源代碼中，您應該停止使用該分支並將其刪除。 （注意：從技術上講，keep a branch alive after reintegrating it有一個'官方'的方式，但由於它相當於刪除和重新創建分支並且更難做到，所以通常不是最好的路線）

這裏的問題是元數據。當你合併分支之間的變化時，Subversion會記錄指示哪些修訂合併的元數據。從分支返回到主幹將元數據附加到主幹，表明分支中的某些修訂已合併。下次合併來自trunk->分支，合併的修訂版本之一是表示分支 - >主幹合併的主幹修訂。此時元數據相當混亂且幾乎是循環的，而且實際上最終可能會通過合併自上次合併後在分支中修改的較舊代碼的代碼來破壞分支。即使合併成功完成，您也會增加未來合併衝突的可能性。一般來說，它非常容易出錯，而不是Subversion設計的用例。爲了更好地解釋爲什麼會導致問題，請參閱上面的鏈接。

總體而言，分行專爲臨時短期開發工作而設計。你所做的聽起來更像是一個長期的分支比分支，這絕對不是Subversion的典型用例之一。這裏有幾個選項。

1）當您從分支合併到中繼時，請不要記錄關於合併的任何元數據。要麼手動合併更改（而不是讓Subversion執行此操作），要麼合併更改，然後在提交之前還原元數據更改。這不是一個很好的解決方案，並引入了複製/粘貼錯誤的機會，但它可能導致更少的問題。你仍然在標準的Subversion工作流程之外工作，所以我希望你仍然會遇到問題。

2）避免將分支部分合並回幹線。如果合併所有分支的更改，請執行--reintegrate合併，然後刪除分支（您始終可以創建一個新分支，即使是具有相同名稱的分支）。如果只需要合併一部分更改，請在主幹（而不是分支）中進行初始開發，然後將從主幹到分支的更改合併。這樣，所有的合併仍然沿着相同的方向進行，最終結果是變化存在於主幹和分支中。 3）考慮使用git。你所描述的工作流更容易用git完成，並且不需要跳過儘可能多的循環來讓它運行。你也可以在Subversion之上運行git，這樣你就可以在你的本地機器上使用一個git倉庫，它可以從Subversion倉庫中提取並推送更改。

4）通過重構代碼來消除對fork的需求，從而不需要單獨的分支。將常用功能分解爲共享模塊，並將差異隱藏在通用接口後面。如果你願意，你可以使用編譯時標誌來選擇要構建的版本。這將消除完全合併的需要。

＃4顯然是最好的解決方案。我明白，在所有情況下都可能無法做到這種事情，特別是當代碼庫很大並且分支機構進行重大架構更改時。如果不可行，我建議選擇＃3。我個人使用這種方法。我的團隊使用Subversion版本庫，但團隊中的一些開發人員（包括我自己）在我們的本地機器上運行git，以便完成Subversion無法做的（或者不容易）更高級的事情。我們不會像您一樣維護任何長期分支機構，但我們經常使用多個短期分支機構併合並它們之間的更改。

有關Subversion關於分支和合並的典型用例的更詳細描述，請參閱the Subversion book。