svn供应商分支
在svn红皮书中，在“Vendor Branch”一章中，建议维护当前/包含最新版本的第 3 方产品，因此从示例中我们最终得到：
repos/vendor/libcomplex/current - contains 1.1
repos/vendor/libcomplex/1.0
repos/vendor/libcomplex/1.1
current/ 的目的是什么？为什么我们需要首先将新版本放入 current/，然后才将 current/ 复制到版本专用目录（例如 1.1）？
我的猜测是为了：
- 使不同版本的 svn 具有可比性。
- 另一方面，版本以更有效的方式存储在 svn 存储库中。
我可以绕过供应商分支中当前/的处理吗？
更新： 我不打算修补供应商代码（至少这是一个计划）。因此，我将使用 svn:external 来使用适当的供应商版本下降。
In the svn red book, in the chapter "Vendor Branch", it is proposed to maintain a current/ containing the latest release of 3rd party product, so from the example we end up with:
repos/vendor/libcomplex/current - contains 1.1
repos/vendor/libcomplex/1.0
repos/vendor/libcomplex/1.1
What is it purpose of current/? Why we need initially put a new version to current/ and only after that to copy current/ in a version dedicated directory (e.g. 1.1)?
My guess it's for:
- To make different versions svn comparable.
- As a side the version are stored in more efficient way in svn repository.
Can I bypass handling of current/ in vendor branch?
Update:
I don't intend to patch the vendor code (at least this is a plan). So I'm going to use svn:external to use an appropriate vendor version drop.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
该供应商分支管理方案的目的是将第 3 方产品的版本放入您的存储库中，以便您在版本之间建立历史记录。如果您只是将版本 1.0 导入到
repos/vendor/libcomplex/1.0并将版本 1.1 导入到repos/vendor/libcomplex/1.1，则 Subversion 中不会有版本之间的历史记录1.0 和 1.1，并且您将无法在 Subversion 中查看版本 1.0 和 1.1 之间的更改。当然，您可以检查两者并使用 GNU diff 来比较它们，但在这种情况下您并没有利用 Subversion 的强大功能。如果您正在创建自己的分支并希望将 1.0 和 1.1 之间的更改合并到您的分支中，历史记录就很重要。如果您希望查看 Subversion 版本 1.0 和 1.1 之间的更改，也可以导入历史记录。最后，拥有历史记录可以更有效地存储数据，因为只存储 1.0 和 1.1 之间的增量。
通过将版本 1.0 导入到 repos/vendor/libcomplex/current ，然后将版本 1.1 添加到同一目录，您可以在 1.0 和 1.1 之间建立历史记录。
The intent of that vendor branch management scheme is to put the releases of the 3rd party product into your repository such that you establish a history between releases. If you simply import release 1.0 to
repos/vendor/libcomplex/1.0and import release 1.1 torepos/vendor/libcomplex/1.1, there will be no history in Subversion between releases 1.0 and 1.1, and you will not be able to view the changes between release 1.0 and 1.1 in Subversion. Sure, you can checkout both and use GNU diff to compare them, but you are not taking advantage of the power of Subversion in that case.The history is important if you are creating your own branch and wish to merge the changes between 1.0 and 1.1 into your branch. The history is also import if you wish to view the changes in Subversion between releases 1.0 and 1.1. Finally, having a history results in a more efficient storage of the data, because only the delta between 1.0 and 1.1 is stored.
By importing release 1.0 to
repos/vendor/libcomplex/currentand then adding release 1.1 to that same directory, you establish a history between 1.0 and 1.1.这是必需的，因为使用 svn_load_dirs.pl 脚本会破坏该目录的内容并将所有内容导入为新内容。
不，你不能绕过它，因为它是必要且有用的。
重点在于新供应商删除的目录和文件相对于旧供应商而言。该脚本处理将新供应商导入到当前供应商中，然后通过“自动手动”删除每个不再存在的文件/目录。然后合并。
It is needed because using the svn_load_dirs.pl script you destroy contentes of this dir and import everything as new.
No you can't bypass it, as it is necessary and useful.
The point is in deleted dirs and files in the new vendor drop respect to the old one. This script handles this importing the new vendor drop into current and then removing by "automated hand" every no more existant file/dir. Then merge.
除了 AlberT 的评论之外，如果您的构建脚本要引用您应该始终看到最新供应商代码的区域，那么拥有专用目录（当前）也有助于获得恒定的路径引用。
In addition to AlberT's comments, having a dedicated directory (current) also helps to have a constant path reference if your build scripts are goign to reference an area where you should see the latest vendor code ALWAYS.
使用 /vendor/current 分支使 /vendor/tag 分支成为纯卷影副本。
我还将当前分支用于供应商主要版本之间的非常小的版本，我认为不需要添加标签。
Using a /vendor/current branch makes the /vendor/tag branches pure shadow copies.
I have also used the current branch for very minor releases in between a vendor's major releases, where I do not see a need to add a tag.