What do you use the svn tags directory for anyways?

Question

Ok so we all know the standard SVN set-up of

trunk\
branches\
tags\

And I realize that the recommendation is that tags should have "special" commits in it. I've never really used the tags directory however and I don't see why I ever would.

My understanding is that tags\ would contain things like "Version1Release\, Version2Release\, ThatTimeWeUpgradedEverthing\" etc. But here's the thing, if you are going in and need to make a change to the Version1Release then it should be a branch, and if tags are supposed to be never-changing then whats the point of making a copy in source-control anyways? Just make a note revision 712 was our version 1 release.

I guess my confusion is that it seems like tags are versions that are never supposed to change. But source control is all about keeping a history of changing files. I know this is a minor organizational argument, but I'm curious what people think.

Answer 1

Tags are supposed to reference immutable "version of the application" of a set of files.
("version of the application" as opposed to "technical internal version number used by the VCS", like revision for SVN, or SHA-1 for Git, or id for ClearCase, or...)
They are supposed to serve as reference to be queried and deployed in another workspace (for testing or UAT - User Acceptance Tests -)

Since SVN implements tags like branches: as directory, the incentive to modify files in a tag can be strong, but would defeat the purpose of a tag. Other VCS has the notion of label (or "baseline") which, once set, can not be moved anymore.

To which George Mauer comments:

Well thats kind of what I was saying. Tags should never be changed so its a very...odd to implement them as branches.

"implements" ? But they did not "implemented" the notion of tag. SVN has no "tag" per se. They just reused their branches and said it could be also used as a tag.

SVN RedBook clearly states:

But wait a moment: isn't this tag creation procedure the same procedure we used to create a branch? Yes, in fact, it is.
In Subversion, there's no difference between a tag and a branch. Both are just ordinary directories that are created by copying.
Just as with branches, the only reason a copied directory is a “tag” is because humans have decided to treat it that way: as long as nobody ever commits to the directory, it forever remains a snapshot. If people start committing to it, it becomes a branch.

Answer 2

We used it to tag specific builds that were interesting but not releases, e.g.: "Investor Demo", etc.

Answer 3

Tags are not intended to be modified, you should make a branch if you want to do that.

You can make a branch from a tag, which is probably what you would want to do, then re-tag the results of that branch as a different version.

You shouldn't checkout a tag for editing.

You don't lose any history by branching(copying) in SVN. It all is linked together.

Answer 4

I create a tag every time I promote a project from a development server to a production server. This gives me a history of what code was promoted to production. If there are any issues, I can quickly roll back to the previous production version.

You would not want to checkout/change/commit anything in the tags directory. It is simply a place to keep a snapshot of your code from a given point in time.

Answer 5

Just make a note revision 712 was our version 1 release.

This works well enough for developers on the team, perhaps (assuming you have a document store to make such notes in), but asking anyone not intimately familiar with the repository to "just remember" gets pretty unreasonable pretty quickly.

For example, say your repository is available over the 'net. A user might choose to check out and build a copy for their preferred, but obscure, flavor of *nix and want to grab a release which is a couple of versions back, before you added a feature they don't like. Tags make this kind of thing easy.

Tags are also excellent as a "trigger point". In my own repositories, committing a tag automatically launches (via post-commit hook) a script which builds, packages, and posts it to our web site.

In the end, tags are cheap copies. If you ever want to "snapshot" your build in a way which represents that the snapshot won't ever change, tag it. It isn't like it costs you much. :-)

Edit:

To address the "implemented as branches" idea — they aren't. Really. In fact, Subversion doesn't implement branching or tagging at all. Those are entirely user-created ideas, both of which happen to use the same command, svn copy. However, you'd also use that command to copy a file within the trunk; there's nothing special about it. And there's nothing inherently special about branches or tags, either. They're just ordinary directories which we've decided to treat specially (and may even enforce that via hooks) to ease project administration.

Answer 6

Just make a note revision 712 was our version 1 release.

But in that case, you have to make an explicit note, store that note somewhere in a place where everybody can see it and look for it.

It's much easier to just create a tag from revision 712 (i.e., copy from r712 to the tag directory) with the name "version 1 release". And everybody immediately knows that this is the release, without first having to look up which revision the version 1 release was.

Answer 7

Just make a note revision 712 was our version 1 release.

To me, making a Tag is making a note that rev 712 was version 1.

It is also very easy to see all of the builds, milestones, releases, etc., just by looking at the Tags folder.

If you consider how Labels worked in VSS, Tags are much faster and easier to work with, but accomplish the same thing. Just don't over analyze the fact that it is made using the copy command just like a branch is.

Edit: If you are paranoid about someone committing changes to a Tag folder, you could use pre-commit hooks to prevent it by user.

Answer 8

In my experience tags are used for release markers, and where you aren't likely to make modifications.

If you create a "release2-0" branch, and then need to make changes (e.g. to fix a bug found post-launch) it no longer represents what you released for version 2.0.

If instead you create the "release2-0" tag and find you need to patch that version, you can create a new branch, make the fix there, and tag that as "release-2-0-1".

This way you can easily access any of your releases.

Answer 9

A subversion repository is just a single tree of files and folders, where you can get any portion of that tree at any version in its history at any time.

As others have said tags/branches/trunk is all just a convention on top of that, subversion allows you to copy one portion of the tree to somewhere else for (almost)free, but in it's core, that's about it.

You're right that you will need a maintenance branch for your version. The tag acts as your name for any particular version sent somewhere external - and the commit comment when you create the tag gives you a chance to explain where it went and why (eg, "public beta release", "requesting comments").

There are several hook scripts out there that prevent you making modifications to a tag, but they won't be implemented by default because some people use subversion in a completely different way (eg, config file backup, etc). Subversion is a generic tool, there's no 'right' way to use it, just strong conventions for common situations.

In fact, collabnet are starting to consider how revision control is used for non-development projects. The whole idea of tags trunk and branches may be irrelevant for some of these.

My convention when thinking about a source code repository is:

• Trunk - the complete list of revisions that may be released to live
• Task - an external description of a job/bug that groups a set of revisions
• Development branch - a set of revisions that aren't yet ready for trunk
• Maintenance branch - a place to collect revisions from trunk for release
• Tag - a named snapshot of a maintenance branch

Tags can also give you a usable url for documentation, eg:

"The release is available at http://svnserver/myproject/tags/1.0" It could be: "The release is available at http://svnserver/myproject/trunk@4483"

But when you're browsing through the repository, you'll never come across @4483 and know that it was in any way special.