從外部儲存庫合併

本文經原位置 http://blogs.collab.net/subversion/do-not-post-mer 的許可轉載。已移除或更新失效連結。

作者：C. Michael Pilato

發布 2008-03-29

對許多人來說，即將推出的 Subversion 1.5 版本被宣傳為「合併追蹤及其他一些功能」之類的東西。投入新合併追蹤功能的工作量大於其他個別領域的投資，這可能是真的。但當然，Subversion 1.5 不僅僅是合併追蹤。此版本還有其他幾個主要功能。而且正如你所預期的，Subversion 社群在過去的一年半中也進行了無數的錯誤修正。但今天我想簡要地討論一個半錯誤修正、半功能，它可能在你不知不覺中溜進來了：從外部儲存庫合併。

Subversion 目前允許你執行合併操作，合併來源位於一個儲存庫中，但目標工作副本（你要合併到的對象）來自不同的（「外部」）儲存庫。畢竟，由於 Subversion 將合併建模為差異的應用，你可能會認為這些差異的來源並不太重要。但這是一個沒人真正討論的功能：Subversion 公開 API 沒有提到它；Subversion 書籍 沒有提到它；Subversion 的版本說明沒有吹噓它。事實上，我之所以知道這個功能存在，是因為我在破解 Subversion 的合併追蹤功能時遇到的程式碼註解。為什麼要如此保密？嗯，這可能是那些意外功能之一，它們並非特別有意要運作，但大多數情況下還是運作了。或者原因可能是它有時只會運作。無論如何，從外部儲存庫合併實際上是一個隱藏功能。

顯然受到「天啊，這應該可以運作」的精神鼓舞，一位 openCollabNet 社群成員找到了這個功能，同時也發現了它的缺點。使用者「argeman」在合併追蹤 beta 計畫論壇上發布了以下內容

我測試了一下 svn 1.5 alpha2（轉換了一些儲存庫，並使用它們進行了一些操作）。到目前為止，它的運作完全正常。唯一仍無法運作的功能（在之前的 Subversion 版本中也無法運作）：如果我嘗試合併來自不同儲存庫的變更，則無法對新增檔案進行合併。

我從未真正使用過從外部儲存庫進行合併，但立即就意識到此功能的價值。我可以將其總結為兩個字：「供應商分支」。供應商分支是一種常見的方式，用於維護對其他人程式碼的私人自訂，而無需逐一變更地反映程式碼變更。有不同的方法可以讓此功能運作。例如，您可以使用個別分支，它們是特定供應商發行套件內容的純鏡像，然後再使用另一個分支，其中包含供應商套件的目前使用版本以及您的私人修改。您可以透過將純供應商版本之間的差異套用至您的自訂副本，來升級您的自訂套件。或者，您可以在版本控制分支中僅保留供應商套件的自訂副本，並使用在未版本化的供應商套件內容之間產生為修補程式的差異，來升級該分支。有些受虐狂完全避免使用版本控制的功能，並僅維護自訂修補程式檔案，而這些檔案需要在每次供應商套件的新版本時更新。（如果您是其中之一，有人可以協助您處理您的疾病。）

然後，從外部 Subversion 儲存庫進行合併的能力提供了一種類似於我先前提到的第一種和第二種方法的混合方法。在此方法中，您只需要維護供應商套件的單一自訂副本，而無需追蹤供應商版本的純鏡像（因為可以從供應商的 Subversion 儲存庫中輕易取得純版本）。但是，現在您可以使用版本控制工具來將這些純版本之間的差異合併至您的自訂副本中，而無需處理雜亂的修補程式檔案。

很遺憾，「argeman」並未發文表示：「嘿，我剛找到這個功能，它很好用！」這篇文章是要告訴我們這個功能有潛力，但無法處理合併後需要新增的檔案。不過，這就是從事開放原始碼軟體開發的樂趣所在。我花了 40 分鐘的時間變更 Subversion 的程式碼來修正問題，並撰寫回歸測試，之後又花了一些時間進行相關的後續修正。因此，當 Subversion 1.5 發布時，我預期從外部儲存庫合併資料的功能將與儲存庫內合併資料一樣受到基本層級的支援。合併來源中的重新命名仍會造成 Subversion 中一貫發生的相同複雜情況，而且從外部儲存庫合併資料時會略過合併追蹤邏輯，但在最常見的情況下，合併應該可以順利完成。