我们有一个由单个构建作业组成的大型项目（Maven，通过 pom.xml，具有多个子文件夹等）。开发人员给了我们三个不同的修订号，并希望我们创建一个可以提供给 (Hudson) 构建作业的标签。
示例：
/ -- 在版本 X
/project1 -- 在版本 Y
/project2 -- 在版本 Z
我可以通过将整个分支同步到 rev X，然后“cd project1”并同步到 rev Y，然后“cd ..\project2”并同步到 rev Z，然后“cd ..”来创建这个标签并创建当前目录中的标签。
我们希望能够从单个命令行创建标签（并且，无需使用 URL 将任何文件同步到我们的本地工作站）。这可能吗？我们尝试了几种变体，但似乎都没有。
谢谢，
肯
I see two approaches to meet your requirement
I will treat your "/" as "trunk" btw. as it wouldnt make sense for creating tags otherwise ;)
copy from revision approach
advantages
disadvantage
mark as stable approach
do this step once in your trunk:
add these two lines:
svn propset svn:externals -F externals .
Whoever checks out your main app will now get the latest versions of your projects when they were ready for release.
development teams for the projects do these steps whenever a new release is ready. They can decide to use the revision number or simply tag HEAD when they are ready:
svn copy http://myrepos/project1/@y http://myrepos/1.0/project1/tags/to-be-released
on release/tag-day:
You can use a revision number too. Problem here is that your application layout indicates that project1 and 2 reside inside your main application "/". If that is not the case tagging and using fixed taggs for release-integration can be verry smooth. ("/" would get sub-tagged too)
real world example:
svn propget svn:externals http://svn.silverstripe.com/open/phpinstaller/tags/2.4.2/
advantages
disadvantages
Tags are just "symlinks" to revision so both scenarios use the same principle. Tagging feels more explicit though. This whole scenario is not a 1:1 copy-and-it-works suggestion but more of a generic model.
您始终可以svn copy手动将内容复制到tags. 如果需要，您还可以编写一个简单的脚本来执行此操作给定三个修订号。
如果复制目标是工作副本的路径（而不是存储库的 URL），您可以稍后一步提交所有内容。