供应商分支中是否需要当前/需要？

Question

我有什么

我有一个 C++ 代码库，svn 用于 VCS。

我的代码使用了几种第 3 方产品。我们使用每种产品的不同版本，并在不同的操作系统（Linux 和 Windows）上使用它们。

第 3 方产品（具有所需版本）存在于编译机上并在编译时使用，因此代码和使用的第 3 方版本之间的关系是松散耦合的。

我想要什么

我想改变现状。这个想法是利用svn vendor branch。 与svn vendor branch 中描述的不同，我们将存储第三方产品的二进制版本，而不是代码本身。这是因为我们从不修补第 3 方代码。

svn:external 将用于使用适当版本的第 3 方产品。这里是 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

问题

在vendor branch章节的svn红皮书中，建议维护一个current/包含最新版本的3rd方产品，所以从例子中我们最终得到：

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

由于我们不修补第 3 方代码，因此我认为维护当前 / 没有任何意义。 这看起来也必须维护它，因此您可以看到 svn 提供了辅助 perl 脚本 svn_load_dirs.pl 来帮助。

我的猜测当前/是必需的：

1. 让不同版本的svn releted，然后svn可比较。
2. 另一方面，版本以更有效的方式存储在 svn 存储库中。

我不认为我们真的需要这些。

所以问题是我们是否可以安全地绕过供应商分支中的 current/ 处理？

Answer 1

我们采用与您建议类似的方法，即将供应商二进制文件引入我们的存储库，然后使用 svn:externals 对这些二进制文件使用相对路径。它工作正常，我喜欢我们没有外部存储库依赖项。

您甚至可以考虑只为每个操作系统维护每个二进制文件的一个副本，即忘记在目录名称中指定版本，只需使用 Subversion 版本作为控制器。这是在您的 svn:externals 属性中使用明确的修订号来完成的，无论如何您都应该这样做。

所以 mymodule/vendor/product1/OS1 上的 svn:externals 将设置为 -rXXX ^/vendor/product1/OS1 其中 XXX 是包含适当的修订版mymodule 使用的版本。

例如，在我们的工具目录下，我们有 nunit 二进制文件。如果 nunit 发布新版本，我们会更新工具\nunit 并在日志中记录发布详细信息。我们所有引用 nunit 的项目都可以（可选地）通过更改相关项目的 svn:externals 属性的修订号来开始使用新版本。如果任何项目不想要更新，他们什么都不做:)

Answer 2

我会说这没关系。这是第三方库的常见情况，您通常没有或不想维护源代码。在这种情况下，存储您想要的二进制版本是完全可以接受的，因为从您的产品的角度来看，是源。

Answer 3

是的，您可以安全地绕过分支中 current/ 的处理。在那本书中，他们使用 current/ 作为第 3 方代码的主干/，并使用从供应商导入的版本对其进行标记。

Answer 4

使用“当前”目录和 svn_load_dirs 旨在让您可以按照您所说的那样保留本地更改。它为文件从一个版本到下一个版本保持连续的历史记录。这允许合并过程检测基础中的更改并允许您保留更改，就像从主干重新设置分支一样。否则，文件每次都被认为是新的，这种“变基”会尝试完全替换文件，而不是合并新的位。

由于您处理的是二进制文件而不是修补它们，因此您可以放心地忽略它。

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，大部分是 .NET 3.5 DLL，带有一些 PDB 和 XML 文件。我发现空间节省非常显着，即使是在我从 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 绝对可以很好地紧凑地存储它，但我认为这是一个很好的节省，非常值得结构和额外的复制操作。

您的里程自然会有所不同。就我而言，拥有所有历史版本非常有用：我的团队支持许多客户，每个客户可能使用供应商软件的不同版本。了解供应商更改了哪些文件的取证价值也有助于预测补丁是否会影响我们的增强功能。