Subversion: how to create a tag with folders at multiple revisions

Question

Hi,

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

Answer 1

You can always do svn copy manually to copy stuff over to a newly created folder under tags. 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.

Answer 2

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.

Answer 3

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

• svn copy http://myrepos/trunk/@x http://myrepos/tags/1.0/
• svn copy http://myrepos/project1/@y http://myrepos/tags/1.0/project1/
• svn copy http://myrepos/project2/@z http://myrepos/tags/1.0/project2/

advantages

• easy to understand

disadvantage

• documentation overhead (What is in this tag?)
• selecting of revisions possible source for error
• overhead scales lineary with number of projects

mark as stable approach

do this step once in your trunk:

• create a file in an editor and call it "externals"

• 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 delete http://myrepos/1.0/project1/tags/to-be-released

• 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

• svn copy http://myrepos/project2/@z http://myrepos/project2/tags/to-be-released

on release/tag-day:

• svn copy http://myrepos/trunk http://myrepos/tags/1.0

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

• documentation is a bit easier via svn history and revision graph
• tagging overhead scales and remains constant on main tag-day

disadvantages

• more complicated to setup & understand (whole team has to)

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.