The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Tags in subversion: What's the point?

Just trying to understand a concept here... I am still  somewhat of a newbie at source control--I've been using it a few years now, but I'm not sure I get the nuances yet.

I use subversion for my personal projects, and it's been a pretty pleasant experience.  I believe that I understand the benefits of branching pretty well now, but I don't get tags.  As I understand it, a tag is a snapshot of the source tree at a given point that is assigned a more friendly identifier like "version-1.0".  It's created just like a branch, but never modified.  I assume that this concept is very friendly to CVS users, since the audit trail of what file was at what rev on the release date can be a nightmare, even if you're working a branch, so it's difficult to rebuild the release, say, for a different platform.  (I hope I'm at least mostly right in that logic, but I'm no CVS expert....)

In subversion, it's not difficult to pull the source for whatever rev you were at when you built a particular production release.  So is there any value left in the tag concept when using subversion?  Am I completely missing something?  :)
Matt Brown
Friday, September 23, 2005
 
 
What if you release V1.0 without creating a tag for it, then you want to release a V1.01 for fix of a specific bug?  But you have code changes and additions in trunk that you don't want to publish as part of the update to V1.0?  That would be one example.  It lets you make a change that then applies only to the tagged version.  You could merge into trunk or from trunk if you wanted, but tag stays separate.

Apart from that it helps you easily identify the released version, without having to remember what constituted a version release, without having to remember what checkin count you were at when you released.  As you say, this isn't something you absolutely need, but it's basically costless to create the tag in Subversion (unlike CVS) so why not do it?

Not sure what other reasons there could be.  I'd like to hear more also.
Herbert Sitz Send private email
Friday, September 23, 2005
 
 
This is copy/paste from the help file of TortoiseSVN, a Windows client for Subversion:

"One of the features of version control systems is the ability to isolate changes onto a separate line of development. This line is known as a branch. Branches are often used to try out new features without disturbing the main line of development with compiler errors and bugs. As soon as the new feature is stable enough then the development branch is merged back into the main branch (trunk).

Another feature of version control systems is the ability to mark particular revisions (e.g. a release version), so you can at any time recreate a certain build or environment. This process is known as tagging.

Subversion does not have special commands for branching or tagging, but uses so-called cheap copies instead. Cheap copies are similar to hard links in Unix, which means that instead of making a complete copy in the repository, an internal link is created, pointing to a specific tree/revision. As a result branches and tags are very quick to create, and take up almost no extra space in the repository."
Berislav Lopac Send private email
Friday, September 23, 2005
 
 
You ask a good question!

Tags provide no more or less granularity that the revision number. So I would guess that tags merely provide the user a means to attach a "friendly name" with which to give a revision number.

"Released this revision to Fred" is easier to recall a month later than "revision 132".

That would seem to be the only real reason to use tags in subversion!
hoser Send private email
Friday, September 23, 2005
 
 
Tags are valuable the bigger your project gets. Otherwise you will find yourself maintaining a list that cross-references revision numbers to releases. If you release multiple builds (say, one for the Japan market and one for the US market) -- do you want to track it all by hand?
Nate Silva Send private email
Saturday, September 24, 2005
 
 
One of the other suggestions from the manual is that you can tag a group of things at different versions.

Say you have versioned in seperate projects Widget 1 and Widget 2, and Application App.

Say there are some upcoming changes to Widget 2 when you release App - such that you want to release App version 3 and W1 version 2 and W2 version 1.

you pull the current version of App and W1 and the older version of W2 out to a working directory to make your release version and then you make the tag - now people don't have to worry about the complex environment and which version of the widgets where actually used, it's all captured.
Gorf
Sunday, September 25, 2005
 
 
Thanks for the comments!  I haven't yet combined separate projects into a single release, so I didn't think of that.  Good to know.
Matt Brown
Monday, September 26, 2005
 
 
I guess I misunderstood how tags are implemented in reference to the 'use almost no space' comment.  I thought the tagged version was a copy of all files, hard copy, normal files, etc, in a separate tree based on the tag name.  So the space used is roughly equal to that used by a normal 'checkout'.
Svn-Kicks-Pvcs's-Behind-Its-Not-Even-A-Close-Match
Friday, September 30, 2005
 
 
When you check out a tagged version of the repository, yes, it makes a complete copy of all those files into your working directory.

But in the *repository*, a tag is just a reference to some numbered repository version. So a tag called "Version 3.0.1 Beta 2" is actually just implemented as a reference to the repository revision 62597 (or whatever).

It's like using a symbolic link in linux. Kind of.
BenjiSmith Send private email
Saturday, October 01, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz