供應商分支中是當前/需要的嗎？

Question

我有的

我有一個C ++代碼庫， svn用於VCS。

我的代碼使用了幾個第三方產品。 我們使用每種產品的不同版本，並在不同的操作系統（Linux和Windows）上使用它們。

第三方產品（帶有所需版本）存在於編譯機器上並在編譯時使用，因此代碼與使用的第三方版本之間的關系松散耦合。

我想要的是

我想改變這種情況。 這個想法是利用svn供應商分支 。 與svn供應商分支中描述的相反，我們將存儲第三方產品的二進制版本而不是代碼本身。 這是因為我們從不修補第三方代碼。

svn：external將用於使用適當版本的第三方產品。 這是svn存儲庫的框架：

svn_repo/vendor/product1/OS1/ver1 <- mymodule using it
         vendor/product1/OS2/ver1 <- mymodule using it
         vendor/product1/OS1/ver2
         vendor/product1/OS1/ver2

         vendor/product2/OS1/ver1
         vendor/product2/OS2/ver1
         vendor/product2/OS1/ver2 <- mymodule using it
         vendor/product2/OS1/ver2 <- mymodule using it

         mymodule/   <- this is my actual code referring to a particular 
                        products from vendor/ using svn:external
         mymodule/vendor/product1/OS1   <- reference to vendor/product1/OS1/ver1
         mymodule/vendor/product1/OS2   <- reference to vendor/product1/OS2/ver1
         mymodule/vendor/product2/OS1   <- reference to vendor/product1/OS1/ver2
         mymodule/vendor/product3/OS2   <- reference to vendor/product1/OS2/ver2

題

在供應商分支章節的svn紅皮書中，建議保持當前/包含最新版本的第三方產品，因此從示例中我們最終得到：

   repos/vendor/libcomplex/current - contains 1.1
   repos/vendor/libcomplex/1.0
   repos/vendor/libcomplex/1.1 

由於我們沒有修補第三方代碼，因此我沒有看到維持當前/的任何意義。 這看起來也必須維護它，因此你可以看到svn提供了輔助perl腳本svn_load_dirs.pl來幫助。

我的猜測當前/需要：

1. 為了使不同的版本svn相關，然后svn可比。
2. 作為一方，版本以更有效的方式存儲在svn存儲庫中。

我不認為我們真的需要那些。

那么問題是我們是否可以安全地繞過當前/供應商分支的處理？

Answer 1

我們遵循您提出的類似方法，即將供應商二進制文件引入我們的存儲庫，然后使用svn：externals使用相對路徑到這些二進制文件。 它工作正常，我喜歡我們沒有外部存儲庫依賴項。

您甚至可以考慮為每個操作系統維護每個二進制文件的單個副本，即忘記在目錄名稱中指定版本，只需使用Subversion版本作為控制器。 這是使用您的svn：externals屬性中的顯式修訂號來完成的，無論如何您應該這樣做。

因此， mymodule / vendor / product1 / OS1上的svn：externals將設置為-rXXX ^ / vendor / product1 / OS1 ，其中XXX是包含mymodule使用的相應版本的修訂版。

例如，在我們的工具目錄下，我們有nunit二進制文件。 如果nunit發布了新版本，我們會更新tools \\ nunit並在日志中記錄發布詳細信息。 引用nunit的所有項目都可以（可選）通過更改相關項目的svn：externals屬性的修訂版號來開始使用新版本。 如果任何項目不想要更新，他們什么都不做:)

Answer 2

我會說這沒關系。 這是第三方庫的常見情況，您通常沒有或想要維護源代碼。 在這種情況下，完全可以接受存儲所需二進制文件的版本，因為從產品的角度來看，這就是源代碼。

Answer 3

是的，您可以安全地繞過分支中當前/的處理。 在那本書中，他們使用current /作為trunk /用於第三方代碼，並使用從供應商導入的版本對其進行標記。

Answer 4

使用“當前”目錄和svn_load_dirs的設計使您可以按照自己的說法保留本地更改。 它保存了從一個版本到下一個版本的文件的連續歷史記錄。 這允許合並過程檢測基礎中的更改並允許您保留更改，就像從樹干重新分支一個分支一樣。 否則，每次都將文件視為新文件，並且此'rebasing'嘗試完全替換文件而不是合並新位。

既然你正在處理二進制文件而根本沒有修補它們，那么你可以放心地忽略它。

Answer 5

我發現本文有助於規划我自己的供應商分支。 但是，我決定為幾個版本創建/ current /文件夾，只是為了看看節省的重要性。 我想我以后可以刪除它，如果它不值得開銷。

我決定只將主要版本發布到/ current /，然后為每個主要版本創建一個分支，並將補丁應用到分支。 最后，為每個結果級別的代碼添加標記。 這非常適合供應商的發布模式，其中補丁（版本的第三段保持不變）僅修改所需的文件，但發布（第三段更改）標記每個文件。

15.1.0.1901
-> update trunk
  -> copy trunk to new branches/15.1.0
  -> copy branches/15.1.0 to tags/15.1.0.1901
15.1.0.2233
-> update branches/15.1.0
  -> copy branches/15.1.0 to tags/15.1.0.2233
15.1.1.3064
-> update trunk
  -> copy trunk to new branches/15.1.1
  -> copy branches/15.1.1 to tags/15.1.1.3064
15.1.0.3299 (bug fix for 15.1.0)
-> update branches/15.1.0
  -> copy branches/15.1.0 to tags/15.1.0.3299

供應商代碼大約為180MB，主要是帶有少量PDB和XML文件的.NET 3.5 DLL。 我發現空間節省很大，即使在我從15.1.0到15.1.1的每個DLL都有變化的中繼的提交。

Version     -> size of repos/db/revs file
15.1.0.2782 -> 19,076 KB
15.1.0.2845 ->     78 KB
15.1.0.2892 ->    130 KB
15.1.0.2907 ->    981 KB
15.1.0.2948 ->  1,021 KB
15.1.1.2998 ->  3,334 KB (new branch)
15.1.1.3064 ->    477 KB

假設每次更新的內容都是19MB，我現在最多只需要133MB而不是26MB，節省80％。 現在我也不會因為磁盤空間而煩惱，Subversion無論如何都能很好地存儲它，但我認為這是一個非常好的節省，非常值得結構和額外的復制操作。

您的里程可能會有所不同。 在我的例子中，擁有所有歷史版本非常有用：我的團隊支持許多客戶，每個客戶可能使用不同版本的供應商軟件。 了解供應商更改的文件的取證價值也有助於預測補丁是否會影響我們的增強功能。