Hi all, I'm hoping to have slightly less controversial discussion than the recent branches-as-first-class-objects thread. That topic did, however, touch on tags.
As discussed previously, "tags" as a convention use the same mechanism as the "branches" convention. The mechanism of svn cp works well for branches. The semantics work as expected (for the most part). That is, the results of the basic operations on the "branch" work as expected. (checkout, update, & commit) In my opinion, the same semantics work less well for tags. My biased mind-set is that a "tag" is a name identifying a specific version of code (a cross product of "branch" and "revision"). In subversion, a directory-path@revision, (e.g., ^/trunk@123) give the correct semantics of a tag. I can checkout the exact version of code. When I am ready to update to a later (or latest) version of the branch, update does the right thing. When I commit, my changes go to the right branch, based on my checkout. But a "tag" that is the result of an svn cp (e.g., ^/tags/TRUNK-STABLE) does not give the same semantics. * Checkout is fine, I get the right version of the code. * Update gives me the message that my workspace is up to date. So I silently miss the fact that the latest code changes I wanted to pull in are over on trunk, not on this tag I checked out from. I think I'm working on ^trunk@HEAD, but I'm not. * Commit does not send changes the "tagged" branch -- oh, I thought I had an version of trunk, but my commit does not go to trunk. If I (or my repo admin) properly protects the tags, I get an error and realize I forgot a switch command. If my hook script isn't set up right, it's even worse. I have a change to roll back, when I eventually notice the mistake. Due to those unfortunate semantics, we've do not use tags at all. Whenever we want to specify a version of code, we use branch@revision. We don't have symbolic names, but we do get the right semantics. We have a couple hundred developers and hundreds of branches, but we do without symbolic tags. Yes, I know I'm stupid and that all our developers should be able to understand how to checkout from tags and then switch instead of update, but I think we have saved a lot of grief. (Aside from the fact that I do not have server-side access and can't implement proper hook scripts on our replicated repos.) So, am not saying there is anything fundamentally wrong with how "tags" work now. They just don't fit our desired semantics, so we don't use them. I am also not saying how a better tag or label feature should be implemented, but for our usage, a symbolic name or symbolic link for a path@revision would be a very useful thing. -Steve
