Best practice for SVN tags?

Question

Should I use them as separate releases? Do I check them back into trunk or branches? Is this all in the red book and I've just wasted your time?

Answer 1

Not sure what you mean by "separate releases", but we copy from the trunk or branch we are making a build of into the tags folder with a descriptive name, like Proj-1.20.33

This way, for each build we have made, we can go back to that specific version. Generally, you would not want to make any real changes in a tag. For us, we go ahead and change some version numbers for the code and installer via our automated build process, so only those changes get merged back, and even then, that is the only thing that would be modifying those particular files.

The SVN Book talks about this a bit in Common Branching Patterns and the Tags entries.

Answer 2

Most people I know who are still on SVN tag their trunk (or current production branch) right before every release.

Answer 3

Do not forget that a tag and a branch are essentially the same thing in SVN: both are the result of svn copy

The trick is, since a tag represents a snapshot, it should be an "immutable" one, in that you should not make any modification on it.

What that snapshot (tag) represents is entirely up to you. it can be:

• a stable state in the development
• a mark just before a complicated merge (in order to go back to it if the merge is too complex to be resolved quickly)
• a release or a patch
• and so on...