A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
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? :)
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.
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."
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!
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?
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.
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.
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'.
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.
Saturday, October 01, 2005
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz