供应商分支中是当前/必需的吗？

我有一个C++代码库和SVN用于VCS。

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

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

我想

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

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红书vendor branch章，建议保持电流/含第三方产品的最新版本，所以从示例我们结束于：

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

由于我们不修补第三方代码，我没有看到任何维护当前/的点。这看起来也得维护它，因此你可以看到svn提供了辅助perl脚本svn_load_dirs.pl来帮助。

我的猜测当前需要/到：

为了使不同版本的svn的releted紧接着svn相媲美。
作为一个版本以更高效的方式存储在svn仓库中。

我看不到我们真的需要这些。

所以问题是如果我们可以安全地绕过处理当前/在供应商分支？

来源

2009-09-15 dimba

我们遵循类似的方法来建议您将供应商二进制文件带入我们的存储库，然后使用svn：externals对这些二进制文件使用相对路径。它工作正常，我喜欢我们没有外部存储库依赖关系。

你甚至可以考虑只维持每个二进制的一个副本为每个操作系统，也就是忘了在目录名中指定版本，只需使用Subversion修订作为控制器。这是通过在您的svn:externals属性中使用明确的修订版编号完成的，无论如何您应该这样做。

所以SVN：上MyModule的/供应商/产品1的外部/ OS1将被设置为-rXXX^/供应商/产品1/OS1其中XXX是含有适当的版本MyModule中使用的修订。

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

来源

2009-09-15 07:40:42 si618

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

来源

2009-09-15 07:23:29 Avi

是的，你可以安全地绕过处理当前/在你的分支。在这本书中，他们使用当前/作为第三方代码的中继，并使用从供应商导入的版本对其进行标记。

来源

2009-09-15 07:55:27

使用“当前”目录和svn_load_dirs的设计，使你能保持你的本地修改，就像你说的。它从一个版本到下一个版本的文件保持连续的历史记录。这允许合并过程检测基础中发生了什么变化，并允许您保留更改，就像从分支中重新分支分支一样。否则，每次都会将文件视为新文件，并且此“重新绑定”会尝试完全替换文件，而不是合并新位。

由于您正在处理二进制文件而不是修补它们，因此您可以安全地忽略它。

来源

2009-09-15 10:28:35

我发现这篇文章有助于规划我自己的供应商分支。不过，我决定为几个版本创建/ 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绝对做得非常好，无论如何都可以保存它，但我认为这是一个相当不错的节省，非常值得结构和额外的复制操作。

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

来源

2010-05-25 13:03:49 Bruce

供应商分支中是当前/必需的吗？

回答

相关问题