Subversion：如何创建包含多个修订版本文件夹的标签
我们有一个大型项目，其中包含一个构建作业（Maven，通过 pom.xml，具有多个子文件夹等）。开发人员给了我们三个不同的修订号，并希望我们创建一个可以提供给（Hudson）构建作业的标签。
示例：
/ -- 转速 X
/project1 -- 版本 Y
/project2 - 在版本 Z
我能够通过将整个分支同步到版本 X，然后“cd project1”并同步到版本 Y，然后“cd ..\project2”并同步到版本 Z，然后“同步到版本 Z，来创建此标签。 cd ..”并从当前目录创建标签。
我们希望能够从单个命令行创建标签（并且无需使用 URL 将任何文件同步到本地工作站）。这可能吗？我们尝试了几种变体，但似乎都不起作用。
谢谢，
肯
We have a large project which consists of a single build job (Maven, via a pom.xml, with multiple child folders etc). Developers have given us three different revision numbers, and would like us to create a single tag that we can feed the (Hudson) build job.
Example:
/ -- at rev X
/project1 -- at rev Y
/project2 -- at rev Z
I was able to create this tag by syncing the entire branch to rev X, then "cd project1" and sync to rev Y, then "cd ..\project2" and sync to rev Z, then "cd .." and create the tag from the current directory.
We would like to be able to create the tag from a single command line (and, without having to sync any files to our local workstation, by using URLs). Is this possible? We have tried several variants but none seemed to work.
Thanks,
Ken
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我看到两种方法可以满足您的要求，
顺便说一句，我会将您的“/”视为“主干”。因为否则创建标签就没有意义;)
从修订版本复制方法
优点
缺点
标记为稳定方法
在主干中执行此步骤一次：
添加这两个文件行：
project1 http://myrepos/1.0/project1/tags/to-be-released
project2 http://myrepos/1.0/project2/tags/to-be-released
svn propset svn:externals -F externals 。
现在，无论谁检查您的主应用程序，都将在您的项目准备好发布时获得最新版本。
每当新版本准备就绪时，项目的开发团队都会执行这些步骤。他们可以决定使用修订号或在准备好时简单地标记 HEAD：
svn copy http:// myrepos/project1/@y http://myrepos/1.0/project1/tags/to-be-released
svn delete http://myrepos/1.0/project2/tags/to-be-released
在发布/标签日：
您可以也使用修订号。这里的问题是您的应用程序布局表明项目 1 和 2 驻留在您的主应用程序“/”内部。如果不是这种情况，标记和使用固定标签进行发布集成可能会非常顺利。 （“/”也会被子标记）
真实世界示例：
svn propget svn:externals http://svn.silverstripe.com/open/phpinstaller/tags/2.4.2/
优点
缺点
标签只是修订的“符号链接”，因此这两种情况都使用相同的原则。不过，标签感觉更明确。
整个场景不是 1:1 复制即行的建议，而是更多的通用模型。
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:
project1 http://myrepos/1.0/project1/tags/to-be-released
project2 http://myrepos/1.0/project2/tags/to-be-released
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
svn delete http://myrepos/1.0/project2/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），您可以稍后一步提交所有内容。
You can always do
svn copymanually to copy stuff over to a newly created folder undertags. If you want, you can also make up a simple script doing this given three revision numbers.If the copy targets are paths into your working copy (rather than URLs into the repository), you can later commit all of it in one step.
在这种情况下，svnmerge 可能可以帮助您。
svnmerge.py wiki 说“通过樱桃挑选对发布分支的特定支持：名称并合并单个修订或修订范围。”
我自己没有检查过，请尝试一下。
svnmerge may help you in this case.
svnmerge.py wiki says "Specific support for release branches through cherry-picking: name and merge single revisions or revision ranges."
I have not checked it myself, do give it a try.