How do I use version control tags?

Question

I have developed a kind of brochure website template that I base most of my clients' websites on. The template and derived sites are stored together in a Subversion repository. Bleeding-edge (but stable) code lives in /trunk; and each website has its own branch, to make customization easier. Now that I'm approaching a 2.0 release, I feel I need to come to terms with tags.

As I understand it, significant releases should be tagged. A tag is merely a pointer to a particular revision, and should never, ever be modified. So suppose I have a tag for version 2.0 of my template, and already there is new code in the trunk. If I want to create a new branch based on 2.0 code, how do I go about it?

Do I branch off /tags/2.0? That can't be right. Where would I commit my changes? I'd have to deliberately circumvent my branch's ancestry. Do I have to manually look up the trunk revision that /tags/2.0 corresponds to, and then branch off that revision in the trunk? That seems ... cumbersome. I believe until recently Subversion didn't even store that information!

Clearly, I'm missing something fundamental. A quick rundown of how tags are actually used (as opposed to what they are) would be helpful. Thanks.

Edit: Where I said "branch off /tags/2.0", I meant to say, "check out /tags/2.0". But that mistake was also the answer to my question. For some reason, I had never thought of copying a tag. Stupid, right? But in my mind, tags were "final".

And by the way, I totally get that tags are just a convention. It was the convention itself that I was confused about, not its underlying implementation.

Answer 1

I put bleeding edge (but stable) into /trunk. When features for a release have been finalized, I copy /trunk to /branches/Foobar-1.2.3.X. I immediately copy /branches/Foobar-1.2.3.X to /tags/Foobar-1.2.3.0 (this makes diffs easier later, I can diff /branches/Foobar-1.2.3.X to /tags/Foobar-1.2.3.0 and see what has changed in my branch, since by that time /trunk is likely to be different). Final development proceeds on the features in /branches/Foobar-1.2.3.X, and as I make releases I copy to /tags/Foobar-1.2.3.1, /tags/Foobar-1.2.3.2, etc. My build system is designed to only pull code from /tags/Foobar-????.

This works for "special" branches, too: /branches/Foobar-WhizzBangFeature-1.2.X

Answer 2

Always create branches from the trunk, unless you want to branch from a point in the past (past tag, branch or old trunk revision).
Also, you cannot easily commit anything onto a tag; at least the TortoiseSVN client protects you with a message.

Answer 3

Yes, make a branch with svn copy in /branch folder of repository for the version you want to branch.

For instance:

/branch
/tags
  /1.0
  /2.0
/trunk

Then for a branch on 2.0:

/branch
  /something2.0
/tags
  /1.0
  /2.0
/trunk

Answer 4

You make a copy (using 'svn copy') of your tag directory under /branches (or wherever you store your branches), possibly using 2.0-hotfix or something similar as branch name (distinct from tag name).

It is as simple as it gets. SVN does not really have tags and branches, just directories and files. It is all matter of your policy.

Possibly maybe a more natural way would be creating 2.0 branch first, stabilizing the code in the branch and then creating a tag from the branch.

Answer 5

I'm going to assume you are using Tortoise SVN. Suppose you have the following situation:

/trunk
/braches
   /branch1
   /branch2
/tags
   /1.0
   /2.0

Then all you need to do is:

• open the tortoise repo-browser
• go to the root and expand things so you can see what you are doing
• select the /tag/2.0 folder
• Ctrl-drag to copy it to the /branches folde
• rename the new folder (or not)

And that's it. You then neded to check out /branches/tag/2.0 (or whatever you called it) to work on it.

What you need to do is always think of SVN as simply being a file system. The names and the meanings you give things in that file system are up to you. The fact that you cannot edit "tags", for example, s just a convention - the underlying file system doesn't care if you edit them or not.