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 firstname.lastname@example.org.
Nick Duane 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. What we do is we tag a release. That's a good thing to do even if you should branch later. Then, when the need arises to fix something in that release, we branch it from that tag. This is a trivial operation: update to the release tag and create a branch right there. Then update to the branch tag. The reasoning is like this: You probably want a tag at the branch root anyway, because that's the only way to get the branch root later. Before you need to work on the release, there's no need for an additional branch tag. So we avoid tag clutter by only tagging releases. Only when we need to make a change to a release, we create a branch starting at the already existing release tag. IMO it's helpful to have a naming convention. We start all normal tags with "t" and all branches with "b". And the tag at the branch root has the same name as the associated branch (except for the starting letter). Gerhard