svn: differences between tags and a revision number reference

Question

This is a similar but not identical question to What do you use the svn tags directory for anyways?; there are some subtleties here that I want to understand.

Besides the following features:

• referencing a particular state of a file tree with a name rather than a number
• modifying name-number associations (but maintaining their history) by changing a particular /subtree/tags/{tag_name} directory
• use svn switch to update your working copy to a particular tag

what else can/should you do with tags?

If all tags do is take a snapshot of a particular subtree root at a particular repository revision, technically you could:

• use /subtree/trunk and subtree/branches without a /subtree/tags directory
• create properties on the /subtree/trunk directory e.g. tag:Release_1.0 = 309, tag:Release_1.1 = 496, etc.

and you'd have a name-number mapping, with revision history, that is readable by tool programs.... it's just that right now the set of svn tools uses the /subtree/tags/ convention for a few things.

Is there any reason to put files into the /subtree/tags/ directory which are not all from the same revision of the trunk?

Answer 1

Not initially

I would say you are acquiring an accurate understanding of how svn works. There is nothing magic about tags, branches, and directories. It's all a single integrated mechanism in svn.

But later... It would be normal procedure to adjust which files are covered by which tag. Imagine a release. While the release may initially get a tag for a single repository version, critical fixes, withdrawn features, and other normal release engineering activities will naturally cause tags to be moved forwards and backwards as needed.

Answer 2

Is there any reason to put files into the /subtree/tags/ directory which are not all from the same revision of the trunk?

Yes, of course.

Assume that revision R was tagged as version 1.0, and everybody is happily hacking away on the trunk. Now support identifies a particular bug in 1.0 is already being fixed in file foo.cpp in revision (R+n) and the fix is an isolated one, that doesn't require any changes in other files. What they can do now is to create a version 1.1 which is a copy of 1.0 (what used to be revision R) except for foo.cpp, where they use revision (R+n), so they have that fix in 1.1.

Answer 3

Tags do not maintain a name/number mapping. The repository revision number is global, so any time you change any file, regardless of whether its on trunk/branches/tags, the number will increment. The value of the tag is that because you don't commit to it (by convention; this is not enforced by SVN), the tagged tree will always be the same as when you tagged it, even though you're getting the HEAD revision when you pull down the tag directory.

Answer 4

A tag in Subversion is a collection of files. It's a convention, no more. Basically, the Subversion folks coded a way to make cheap copies, used it for branches then decided that rather than implement a second mechanism for tags, what they had already was perfectly sufficient and re-using the concept meant one less thing for the user to learn and one less thing for tool-makers to have to interface with.