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.
Thanks. I can see I definitely need to tag since, as you pointed out, the branch tag will give me the tip as opposed to a specific release. It seems as if our group often has developers working on features of different release at the same time so I'm not sure if utilizing the trunk for most of the development is going to work. I'll have to think about this some more. Assuming we could adopt the guidelines you state below, let me give an example to make sure I understand what you're proposing. We develop in the trunk heading towards a release. At the point where we want to release the code for testing we tag it as that release. We can then possibly start working on the next release while we're waiting for bugs to be reported. If bugs which need fixing are reported we branch at the tag we defined and make the fixes in that branch. When we're all done fixing bugs we...? I know we eventually want to merge back into the trunk so that the trunk contains the bug fixes, but what about tagging the release? I guess the only spot to tag it is in the branch since we can't tag the merged trunk as the release since that will most likely have other changes to it. And since it's unlikely that we'll ever release from the trunk without having to fix some bugs, then we're always going to have to create a branch for this release. And once you create a branch for the release it seems as if the trunk's release tag's usefulness either diminishes or becomes not useful at all since at this point all tags for the release will now be from the branch. Would an alternative to the trunk release tag be to branch and tag the root of the branch? I realize you've created a branch that you might not need, but that will only happen if you've released something that requires no bug fixes. And again, this root of the branch tag doesn't appear useful once bug fixes are applied to the branch. Can I set a tag on a branch and have that tag visible without having to specify that branch? What I mean is let's say I fix all the bugs in the branch and tag it as t-3-8-rtm. Does someone need to know the branch if they want to get this release or can they just specify the tag and get that release? Nick "Bo Berglund" <bo.berglund at telia.com> wrote in message news:7c2vd29fpat6n8f5b8jjimc6cd4gpi2ki7 at 4ax.com... > On Sun, 13 Aug 2006 14:45:08 -0400, "Nick Duane" <nickdu at msn.com> > wrote: > >>Thank you. I'll look this over and see how well this will work for us. >>The >>one thing that comes to mind at this point (assuming I understand what >>you're saying below) is that the releases are simply tags in the trunk as >>opposed to branches. Now maybe a symbolic tag and a branch are pretty >>similar, as I said I'm new to CVS so I'm not sure about that. I'm >>thinking >>that I would like a branch for each release we intend to make so that we >>can >>have a well defined place to pull releases from as opposed to just taging >>the trunk at a release. Plus we often have times when developers are >>working on more than one release at a time and thus we'll need separate >>locations for those. > > Whenever you do a release from the trunk you should put a tag right > there to marke the sources that are part of that release. > Notice that a tag is a symbolic marker that is fixed to a set of files > (typically those you have in your sandbox) at a certain revision level > (again the revisions you have in your sandbox). It does not matter if > the sandbox is on a branch or on trunk, the same logic applies. > > A branch is just a special type of tag that means that you can > actually commit changes to it. The branch tag moves along with the > committed revisions on the branch, it is not stationary. > So it is not a good idea to mark a release by a branch tag! > > Afterwards you can create the bugfix branch for that release when > needed (at a later time). Nno need creating a branch that will never > bne used..... > > Note that even if you create a branch right now you should > nevertheless *also* put a regular tag at this position because a > branch tag will move along with the sources committed on that branch > and when you later check out the branch you will get to the tip of the > branch rather than to te root. And (unfortunately) there is no way you > can set the tag on the root of the branch once you have started > working on it. So you are better off *always* tagging releases on > trunk and then making branches off these tags when needed only. > > HTH > > /Bo > (Bo Berglund, developer in Sweden)