Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Nick Duane wrote: > Good. So what happens when I checkout that tag and then make a change and > commit? Am I committing to the trunk or the branch? Neither. You can't commit to code checked out on a tag. You only can commit to code checked out on a branch (or the implied HEAD branch). If you want to commit code to a tag, you need to branch that tag first. WRT your release scheme, this would work something like this: - You have a branch, say b3_7_3. This branch contains a number of tags, for the different bug fix releases you had; say t3_7_3-1 and t3_7_3-2. Another bug is reported and needs to be fixed. The developer checks out the /branch/ b3_7_3, fixes the bug and commits. This code is now the 3.7.3r3 version, and gets tagged as t3_7_3-3. You use always the branch b3_7_3 when you want to work on the code for the 3.7.3 release. You use the various tags when you want to replicate an earlier release, but you can't work on them. > (... some time going by before I hit send while I'm thinking about this and > remembering someone in a reply to one of my posts said you can only commit > on branches not on tags...) This is correct. > So I guess if you need a certain release because you need to add more fixes > to it, then you need to checkout that branch at that specific release. But > I can't see you needing a specific tag of a branch unless: > > 1. You just need to build it. > 2. You intend to create a new branch at that specific tag. You may want to be able to recreate the earlier build. My (and many other's) guideline is to tag everything that gets published, and then some :) It's not a problem at all to have a few tags you will never need. It is a huge problem if you would need a tag and don't have it... > I can't see you needing the tag to make bug fixes in that branch since you > would always apply bug fixes at the tip. This is correct. The tags are not for bug fixes. They may be important to be able to replicate a bug, though -- the behavior may have changed by unrelated fixes in a later bug fix release. So if your customer reports a bug using an earlier version, you may want to be able to build and run that version. Gerhard