從分支分支，重新整合合並和mergeinfo

Question

我有一個從主干開始的分支A和一個從A開始的分支B。定期進行從主干到A的合並，然后再執行從A到B的合並。 當我想將A和B合並到主干時，我想遵循這種方式：

• 從B重新合並到A
• 從A重新整合合並到主干

這是正確的嗎？ 還是會引起合並信息問題或其他問題？ 在這種情況下，最佳做法是什么？

Answer 1

Subversion因合並不當而受到批評（有時是不公平的）。 實際上，Subversion確實擅長合並。 要了解您需要做什么，您需要了解Subversion如何合並。

通常，Subversion會執行標准的三向合並（稍后將進行解釋）。 它將兩個文件合並到共享的最后一個祖先。 這樣，它可以判斷文件中的哪些更改來自它所在的分支，以及哪些更改來自另一個分支。

因為分支“ B”來自於主干的分支“ A”。 您可以從主干到B或從主干到A合並。這些合並應該可以正常工作。 如果您要合並從分支B或分支A枯萎到主干或另一個分支的一組特定更改，那么一切都應該很好。

現在，我說（某種程度上）執行標准的3路合並 。 編寫Subversion是為了允許您指定在一個分支中進行的特定更改集，以與另一個分支合並。 合並時，Subversion不會查看要合並的文件，它從基礎（最后一個共同祖先）開始，然后應用為合並考慮的那些更改。 在這種情況下，當您確切指定要合並的內容時，Subversion會完成出色的合並工作。

因此，如果您指定分支“ A”具有特定更改，並且希望將此更改合並到分支“ B”或主干，則Subversion在合並方面做得很好。

當Subversion開始跟蹤先前合並到分支或主干中的存儲庫修訂時，Subversion 1.5中的情況開始發生變化。 這阻止了我合並以前合並到分支中的更改，但是這也使我變得懶惰。 懶惰沒有錯。 我高度贊同。

想象一下，我在主干的修訂版100中創建了一個功能分支。 我在版本100處創建了分支。假設這是我的倉庫中所做的修訂的列表：

• 分行 ：103105108
• 行李箱 ：101102104105106107

當我從主干合並到功能分支時，並且沒有指定要合並的修訂版本，Subversion會為我完成任務。 它知道最后一個共同祖先是修訂版100。然后，它看到並發現修訂版101、102、104、105、106和107的主干上的更改尚未應用於我的分支。 然后櫻桃選擇這些特定的更改並將它們合並到我的分支中。

• 分行 ： 103105108109
• 行李箱 ：101102104105106107

修訂版109是我合並的結果。 為了跟蹤更改，Subversion在修訂版109上添加了一個svn:mergeinfo屬性，該屬性表示trunk：101-107已合並到分支：上。 讓我們做更多的工作：

• 分支 ：103 105 108 109 110 111
• 行李箱 ：101102104105106107112113

我想再次從樹干合並到分支。 如果我不偷懶，我會指定我要將修訂版112和113合並到我的分支中。 但是，由於懶惰，我讓Subversion完成了工作。 Subversion從svn:mergeinfo看到，所有從101到107的主干版本都已經合並到我的分支中。 因此，Subversion為我選擇了修訂版112和113：

• 分支 ：103 105 108 109 110 111 114
• 行李箱 ：101102104105106107112113

然后Subversion創建了修訂版114，並設置svn:mergeinfo表示從修訂版101到修訂版113的主干上的所有更改都已合並到我的分支中。

現在，我已經完成了功能，我想將在分支上所做的所有更改合並回我的主干。 如果我不是那么懶惰，我會指定我希望將修訂版103、105、108、110和111合並到我的主干上。 如果我這樣做了，那絕對沒有問題。 Subversion在合並方面做得很好。

注意，我沒有指定要合並的更改109和114（兩個更改以粗體顯示）。 為什么？ 因為這些不是我分支上的更改，所以它們是我合並到分支上的主干更改。 如果指定了這兩個修訂版，則將重新應用我的主干更改回我的主干。

但是，我很懶，並且我希望Subversion為我完成工作。 Subversion查看我的分支，並查看所有這些更改，包括更改109和114，並希望將其合並到我的主干中。 不好。

因此，Subversion在這里做了一些特別的事情。 如果我們認為文件和修訂是要應用於文件的變更集，則基本上是將我在主干上進行的所有更改都應用到分支上，而將所有在分支上進行的更改都應用到我的樹干上。 換句話說，當我完成此分支到主干合並時，我的分支和主干將匹配。

這就是重新整合合並的工作。 與正常的合並不同，常規合並將兩個文件中的更改與基本修訂進行比較，然后仔細應用，而分支上的所有更改都將應用於主干，而無需將其與基本修訂進行比較。 重新整合合並是兩種方式的合並。 分支與主干之間的任何差異都將被覆蓋。

讓我們看看會發生什么：

重新整合之前

• 分支 ：103 105 108 109 110 111 114

• 行李箱 ：101102104105106107112113

• svn:mergeinfo的分支現在顯示trunk:101-113

重新融合后

• 分支 ：103 105 108 109 110 111 114

• 行李箱 ： 101102104105106107112113115

• svn:mergeinfo的分支現在顯示trunk:101-113

• svn:mergeinfo在樹干上現在顯示branch:103-114

讓我們在中繼上做更多工作，只是向您展示如果我繼續使用功能分支會發生什么。 我將在中繼上再進行兩個更改：

• 分支 ：103 105 108 109 110 111 114

• 外線 ：101 102 104 105 106 107 112 113 115 116 117

• svn:mergeinfo的分支現在顯示trunk:101-113

• svn:mergeinfo在樹干上現在顯示branch:103-114

現在，我想將這些更改合並回我的功能分支。 如果我自己摘櫻桃，我會指定我要對分支進行修訂116和117，因為這是我剛剛進行的兩個更改。 再說一次，如果我勤奮好學，那么Subversion合並就可以了。 但是，我很懶，將讓Subversion進行摘櫻桃。

Subversion查看svn:mergeinfo並看到我已將更改103更改為114到我的分支上。 現在，它在我的主干上看到三個新更改：更改115、116和117。但是，更改115是我重新整合合並的結果！ 115中的所有更改都已經在分支上。 讓Subversion進行挑選將導致災難。

這就是為什么告訴您在重新集成分支后不要重用它的原因。 解決此問題的方法是從主干到我的分支上執行svn merge --record-only -c 115 。 實際上不會進行任何合並，但是現在Subversion將記錄101到115的更改在我的分支上。 如果我這樣做了，然后從主干到分支進行了合並，則Subversion將跳過選擇更改115，而僅執行更改116和117。

---

既然您了解了Subversion如何進行合並跟蹤以及什么是重新整合合並，我們就可以看一下您的情況：

• 您從樹干分支到分支A
• 您從分支A分支到分支B
• 您從中繼合並到分支A
• 您從分支A合並到分支B

如果您是一個勤奮的年輕程序員，每天早晨5點醒來奔跑5英里，只是為了讓您有工作的心情，則可以指定要合並到其他分支或主干的每個分支的修訂版本。 如果您這樣做了，那完全沒有問題，您可以進行標准合並，並在健身房進行了充分的鍛煉之后，准備好進行每天100公里的自行車騎行。

如果您是典型的技術人員（即懶惰的人），並且希望Subversion為您處理版本的選擇，則情況會有些不同：

• 您將所有更改從分支A合並到分支B。現在，分支B將包括分支A上的所有修訂。
• 你做分支B的重返合並到分公司A.現在所有對支路A和支路B您的修改將在兩個分支。
• 您將主干與分支A進行常規合並。分支A包含您在分支A上所做的所有更改。此外，還包含分支B和主干上的所有更改。
• 您將分支A（已經包含您的分支B更改） 重新整合到主干上。 現在，主干，分支A和分支B都包含相同的更改集，並且所有三個更改都應匹配。
• 現在，除非您執行svn merge --record-only記錄分支B到分支A的重新集成更改到分支B以及分支A到主干的重新集成更改到分支A上，否則您永遠不要再使用分支A或分支B。

---

Subversion 1.8的重要更改

知道在Subversion中執行常規合並還是重新合並合並可能會出現一些錯誤。 這是一個手動過程，如果我作為一個普通的人犯了一個錯誤（在最糟糕的時候我會做的），這可能是一場災難。

在Subversion 1.8中，Subversion現在嘗試通過查看svn:mergeinfo來確定您進行合並的方式以及何時必須進行重新集成合並。 因此，您不再需要在合並時指定--reintegration標志。 Subversion還可以確保，如果在將分支重新集成到另一個分支或主干后重新使用它，則不要重新應用在重新集成過程中發生的更改。

如果您想進行很多功能分支，則應使用Subversion 1.8，它將為您處理合並跟蹤中的許多錯誤傾向。 如果您使用的是Subversion 1.8，則應該能夠將分支B合並到分支A並合並到中繼中，而不會出現任何問題。