在svn red book的“供应商分支”一章中,建议保持当前/包含最新版本的第三方产品,因此从示例中我们最终得到:
repos/vendor/libcomplex/current - contains 1.1
repos/vendor/libcomplex/1.0
repos/vendor/libcomplex/1.1
当前/是什么目的?为什么我们需要最初将新版本置于当前/并且仅在此之后复制当前/在版本专用目录(例如1.1)?
我的猜测是:
我是否可以绕过当前/在供应商分支中的处理?
更新: 我不打算修补供应商代码(至少这是一个计划)。所以我将使用svn:external来使用适当的供应商版本。
答案 0 :(得分:3)
该供应商分支管理方案的目的是将第三方产品的版本放入您的存储库,以便您在版本之间建立历史记录。如果您只是将1.0版导入repos/vendor/libcomplex/1.0
并将版本1.1导入repos/vendor/libcomplex/1.1
,则版本1.0和1.1之间的Subversion中将没有历史记录,您将无法查看版本1.0和版本1.0之间的更改。 1.1在Subversion中。当然,你可以检查两者并使用GNU diff来比较它们,但在这种情况下你没有利用Subversion的强大功能。
如果要创建自己的分支并希望将1.0和1.1之间的更改合并到分支中,则历史记录非常重要。如果您希望在版本1.0和1.1之间查看Subversion中的更改,则还会导入历史记录。最后,拥有历史记录可以更有效地存储数据,因为只存储了1.0和1.1之间的差值。
通过将版本1.0导入repos/vendor/libcomplex/current
,然后将版本1.1添加到同一目录,可以建立介于1.0和1.1之间的历史记录。
答案 1 :(得分:2)
这是必需的,因为使用 svn_load_dirs.pl 脚本可以销毁此目录的竞争对手,并将所有内容导入为新内容。
不,你不能绕过它,因为它是必要和有用的。
关键在于已删除的dirs和新供应商中的文件与旧版本相关。此脚本处理此操作将新供应商下拉导入当前,然后通过“自动手”删除每个不再存在的文件/目录。然后合并。
svn_load_dirs.pl
包含多个商品的供应商 很少删除,添加和移动 使升级过程复杂化 每个连续版本的 第三方数据
答案 2 :(得分:2)
除了AlberT的评论之外,拥有一个专用目录(当前)也有助于获得一个恒定的路径引用,如果您的构建脚本是goign引用一个区域,您应该看到最新的供应商代码ALWAYS。
答案 3 :(得分:1)
使用/ vendor / current分支使/ vendor / tag分支纯阴影副本。
我还在供应商的主要版本之间使用当前分支进行非常小的版本,我认为不需要添加标记。