In my company, we have had a policy of tagging every release. Someone new joined, and he suggested that instead of formally using a Tag, we could just leave a comment for the release build when it is checked in. I like using a Tag, but, obviously, we can also get to the source code for a build also by looking for the comment. The only advantage I see is that because our product spans multiple technologies, we can group the source code for both in the same directory with a folder for each. Is there some other advantage of tagging releases that I'm missing? BTW, we are using SVN.


5 Answers 5


A tag in subversion is technically the same as a branch. It is only convention that keeps you from modifying a tag after it was created.

Last year I had a situation where we were very happy that we use tags in subversion.
We had created a release and tagged that release. In parallel to the acceptance tests on the release, normal development continued on the trunk of the repository. The problem was that late in the acceptance tests, a critical issue was found that absolutely had to be solved, but the new stuff that was being developed could absolutely not be included in the release, because it was far from being stable enough.
We resolved that finally by making use of the fact that under the hood a tag is the same as a branch, so we made the change directly on the tag. If we had used check-in comments to 'tag' our releases, that would not have been as easy to do.

Besides that, if your project consists of multiple projects that evolve at a different rate but are always released together, then a subversion tag ensures that you have a correct snapshot of all the projects at the time of the release, even if some of them haven't changed since the last release. If you use check-in comments to mark a release, you must make a check-in on each project, even if nothing has changed.

  • 2
    Couldn't I also get a snapshot by getting the Revision Number for the release from the comment and then doing a checkout using the Revision Number? Wouldn't this "snapshot" also be valid?
    – OneSource
    May 14, 2014 at 9:44
  • 2
    @OneSource: You could get a snapshot by checking out a particular version number, but usually you want to do more than just get a snapshot, such as making a change and checking that changed version back in. May 14, 2014 at 10:11
  • Now I get your point. Since, as you stated in your answer, that a Tag in Subversion is essentially a branch, then the "Tagged" version of the source could be modified without any later changes to the code affecting the tagged snapshot that we are working on.
    – OneSource
    May 14, 2014 at 10:28
  • 5
    In @Bart van Ingen Schenau situation, I would have not modified the tag directly, I would have copied the tag in a new branch, modified the branch and then tagged again when finished to fix the issue. In this way you have both version tagged, and you can go on with the development in the branch if you ever need to. May 14, 2014 at 13:31
  • 1
    @DavideGualano: That is indeed a better way to deal with it. In this case, management didn't want a new tag/release candidate and there won't be any further maintenance on that release. May 14, 2014 at 13:39

Some customer who cannot upgrade to a newer version ask you for support for version x.y.z. A tag with that release will help you identify the code you need to inspect. Ask the new guy to search the release using commit comments. Please, do it!

  • 1
    Precisely this. The point of a tag (which is in many ways just a formalised comment in source control systems other than Subversion; SVN's a bit weird under the covers) is to allow you to see the exact state of the code at a precise moment. May 14, 2014 at 8:40
  • Not to mention that branches/tags are a cheap operation in SVN.
    – JensG
    May 14, 2014 at 9:27
  • 1
    Can't we also get the exact state of the code at a given moment by using the Revision Number from the comment and doing a Checkout?
    – OneSource
    May 14, 2014 at 9:45
  • 2
    Yes, but it is easier to checkout from tag release-1.2.3 than checkout revision 9876. May 14, 2014 at 12:41

A tag is precisely made to be able to get the exact snapshot of the sources at the moment you created it. It is 1000000 times more convenient than looking at the submit comments....especially if your release requiered several commits (or more).

Furthermore, the case where a important bug is dicovered in acceptance or in production while the development is ongoing and not stable enough is quite common! In that case you have to create a branch. As others mentioned, a tag is beyond the scene a branch in SVN so you are saved in that case but tagging can also save your life with other tools because many tools allow you to create a branch from tag (CVS, TFS and certainly others). Just try it with comments only!


Yes, you can use the revision number to uniquely identify a snapshot in time.

But... where do you record which revnum matches which release? Will you keep a spreadsheet that says "release 4.2.1" is Revnum 18345? Not recommended.

However, creating a Tag 'branch' does exactly this without the need for spreadsheets or external tooling - if you remember a branch in SVN is just a copy of the repository state (like a symlink) then you realise that a Tag is not much more than a pointer to the revision you want to remember. You get all the benefit of a snapshot in time, but with the advantage of being able to name it something meaningful.

You also get other benefits, as its a branch, you can make patch fixes to it. Code made to trunk can be merged into it when necessary. You can create a new branch from that branch so you can make a forked product if you need to. You can switch your working copy to the Tagged release with a single command. All of this can also be done by recording the revnum, but its much easier to use a Tag, and as it doesn't cost anything you might as well go with the easy option.


Another reason to use tags instead of revision numbers to track what you released is it's easier to keep links/references to tags than to revisions of trunk (or branches). References to particular paths at some old revision can break if you reorganize your trunk (or branch) folder layout in the future. Tags don't change (by convention), so they don't have that problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.