Re: Branching vs Tagging for release candidates

[Roddie Grant]

On 8/7/09 04:07, "Alan D. Salewski" <address@hidden> wrote:

> On Tue, Jul 07, 2009 at 11:12:49AM -0400, Greg Akins spake thus:
>> I'm struggling with getting release candidates ready while still
>> allowing my development team to work on new functionality.  Doing some
>> parallel work instead of working serially on all new features.
>> 
<snip> 
>> Greg Akins
> 
> Hi Greg,
> 
> A few possible alternate approaches:
> 
> After creating the branch that will become the release (6.1 above), you
> could apply fixes to the branch first, and then to the trunk
> (separately). 
<snip>
> 
> You could also introduce new features on individual branches, and when a
> feature is deemed stable merge it into the trunk.
<snip>
> 
> However, it seems that your work patterns more naturally fall into the
> following scheme: you do all work on HEAD until nearing a release. At
> some arbitrary point you declare the trunk "stable-ish" for release and
> require any radical changes to happen on a branch (that tracks HEAD).
<snip>

This thread has been very useful, and I'd appreciate pointers to more about
the daily handling of CVS.

My knowledge of CVS is based mainly on Essential CVS by Jennifer Vesperman;
it's a good book but rather theoretical. I'd be interested in knowing more
about how CVS is used in practice.

For instance, how do users record details of tags? And by this I mean the
nitty-gritty - is it in special software...in Excel...in a notebook...on the
back of an envelope... And what do you record?

Similarly, what sort of things is it useful to include in commit log
messages?

I realise that what other people do may not be directly relevant to me, but
it would still be useful to see examples. I'm a one-one-band web developer
using CVS to manage development, test and live versions of each site. Some
aspects of CVS make life so much simpler, but I have the feeling that I'm
not getting the most out of it.

Thanks

Roddie Grant