Subversion 供应商分支机构
设置 Subversion 以使用供应商分支时的最佳实践是什么？ 我们的存储库是针对单个项目构建的。 我们使用的是 subversion 1.6.2 和 tortoiseSVN 1.6.3。
文件夹结构示例：
Project1
/tags
/branches
/trunk
Project2
/tags
/branches
/trunk
- 我应该将供应商文件夹放在哪里以及它应该具有什么结构？
- 有使用 tortoisesvn 客户端的示例吗？
What is a best practice when setting up subversion to use vendor branches? Our repository is structured for individual projects. We are using subversion 1.6.2 and tortoiseSVN 1.6.3.
Example folder structure:
Project1
/tags
/branches
/trunk
Project2
/tags
/branches
/trunk
- Where would I put the vendors folder and what structure should it have?
- Is there an example using the tortoisesvn client?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Subversion 手册中有专门关于供应商分支的部分。
基本思想是，通过一组跟踪外部更改的文件夹（仅是外部更改，而不是您对其进行的修改），将未修改的当前版本导入到存储库中。 类似于“.../repos/vendor/(software)/current”。 然后立即分支到“.../repos/vendor/(software)/(software-version)”。 随着新版本的发布，更新“当前”目录并创建一个新分支，例如“.../repos/vendor/(software)/(next-version)”。 这使您（和 svn）可以对未修改的源进行比较，以了解外部更改的内容。
对于对软件的修改，请将“（软件版本）”分支到您自己的项目中，例如“.../repos/(my-project)/trunk/(software)”。 当您升级到下一个版本的 3rd 方源代码时，告诉 svn 将“(software-version)”和“(next-version)”之间的差异合并到“trunk/(software)”的工作副本中。 这会将所有外部更改拉入主干，从而巧妙地升级项目源。 像平常一样对项目进行分支和标记。
Subversion 发行版包含一个名为“svn_load_dirs.pl”的 Perl 脚本，它可以在升级“vendor”项目时提供帮助。 它会发现已删除、添加和重命名的文件，并根据需要修改您的工作副本，例如“（当前）”。
The Subversion manual has a section specifically on Vendor Branches.
The basic idea is you import the current release, unmodified, into the repository via a set of folders which track the external changes (just the external changes, not your modifications to it). Something like ".../repos/vendor/(software)/current". Then branch right away into ".../repos/vendor/(software)/(software-version)". As new releases come out, update the "current" directory and create a new branch, such as ".../repos/vendor/(software)/(next-version)". This lets you (and svn) do diffs on the unmodified source to arrive at what changed externally.
For your modifications to the software, branch the "(software-version)" into your own project, something like ".../repos/(my-project)/trunk/(software)". When you upgrade to the next version of the 3rd party source, tell svn to merge the difference between "(software-version)" and "(next-version)" into a working copy of "trunk/(software)". This pulls all external changes into trunk, neatly upgrading the project source. Branch and tag the project as normal.
The Subversion distro includes a Perl script called "svn_load_dirs.pl", which can help when upgrading the "vendor" project. It discovers deleted, added, and renamed files and modifies your working copy of, for example "(current)", as appropriate.
对于以后接触此问题的任何人来说，值得知道的是，从 SVN 版本 1.8 开始，James 对此问题的回答中描述的处理供应商分支的记录方法已发生变化。
在撰写本文时，新文档仍在最终确定中，要查看它，请查看 SVN 书籍第 4 章的“供应商分支”部分：http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html。 请注意该页面顶部有关正在进行的文档的警告。
For anyone coming to this at a later date it is worth knowing that as of SVN version 1.8 the documented method for handling vendor branches described in James' answer to this question has changed.
At the time of writing the new documentation for this is still being finalised, to see it look at the Vendor Branches section of Chapter 4 of the SVN Book: http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html. Please note the warnings at the top of that page re the documentation being work in progress.
你说的是对的，但实际操作中你会发现一个很大的问题。
当你将供应商项目导入到你的 subversion 存储库中时（假设供应商项目是一个很大的项目，比如 apache httpd 2.2），你会发现不可能在每个目录上导入 svn:ignore 属性，因为不存在任何导出工具只能通过访问 WebDAV 界面来执行此操作（有 svn 管理工具可以导出 svn 属性，但需要直接访问供应商存储库）。
因此，当您导入供应商项目时，您必须首先从供应商 svn 存储库导出原始项目，然后将文件导入到 svn 后，您将为项目内的每个目录手动设置 svn 属性。 这是一种非常全面的方法，但如果您确实想修改供应商项目并跟上他们的修改，这是唯一的方法。
What you say is true but in practice you will see a very big problem.
When you import the vendor project into your subversion repository (and supose the vendor project it's a big one let's say like apache httpd 2.2) you will find that it is impossible to import the svn:ignore properties on each directory due to the fact that there does not exist any export tool that can do this only with access to WebDAV interface (there is svn admin tool that can export svn props but requires direct access on vendor repository).
So when you import a vendor project you will have to export first the original one from vendor svn repository and after importing the files into your svn you will set the svn props manually for every directory inside the project. A very paintfull method but is the only one if you really want to modify the vendor project and keep up with their modifications.