Subversion: Is there any good reason not to create a Tag from multiple revisions?

Question

I know this is possible, and there are various ways to do it, but is there any good reason NOT to create a tag from multiple revisions?

What I am proposing to do is create a program based on the SVNKit and Jakarta POI that reads a list of build artifacts from an excel spreadsheet / CSV file (a mix of java class files and other stuff) at various svn revisions, creates a TAG out of it, and this TAG is what becomes the next proposed release.

I like this approach because:

1. We have some documentation (a baseline if you will) detailing exactly what is going into each release.

2. It gives our release manager something to do (without simply checking out the head or having to learn about complicated things like branching and merging)

3. Developers can check-in whatever they want when they want without being constricted by any such concept as a 'release window'. I.e. restricting developers from checking in just prior to a release.

I distrust this approach because:

It feels like I'm violating basic svn principles (although I'm not sure what).

It is because of niggling doubt that I'm putting this idea out there for people to kick the tires so to speak. What do you guys think?

Answer 1

You're not violating any svn principles by doing this. Tag is not an inbuilt subversion construct, just a convention that people use to aid with the build process. Normally people would want their tags to be based off a single revision, but again that is only convention. Do you really have a situation where the good code to ship consists of historical versions of some files but current versions of others?

If this approach works for you, then go for it. However, to avoid confusion for anyone used to the normal definition of 'tags', perhaps you could call the directory something else? "Builds" perhaps?

Answer 2

Developers can check-in whatever they want when they want without being constricted by any such concept as a 'release window'. I.e. restricting developers from checking in just prior to a release.

The traditional SVN way to do this is to always work in a branch, never in a trunk. This way you can commit whenever you wish, you just will not merge into a trunk in the "release window" (when the trunk is "frozen")