[cvsnt] Branching/Tagging Best Practices

[Arthur Barrett]

Ryan,

Tagging/branching best practice is closely related to your workflow, eg:
do several developers work on the same file in the same project (ie:
release 1.2 project) at the same time? (ie: concurrent development) or
is the work scheduled in linear fashion?

> ## Rule 2: Do formal bug fixing on a branch:
> 
>   a) tag/branch and release to testers...
>     cvs tag release-1_0_1-tag ## always has an odd 3rd 
> number, tag instead 
> of rtag to keep sanity from concurrent commits
>     cvs rtag -b -r release-1_0_1-tag release-1_0_1 module1 ## 
> rtag okay here 
> because we reference previous tag
> 
>   b) move "MAKESTABLE" branch alias so that the testers can 
> just do an 
> update on their MAKESTABLE working directory
>     cvs rtag -A -r release-1_0_1 MAKESTABLE module1


There is no need to branch to do a bug fix, this is old thinking based
on old-cvs's lack of user defined changesets.  

We see a lot of:
 Trunk = next major release
 Branch = each release
 Branch off Branch + ACL = promotion level (testing, releasing)
 Tag / alias tag each release

So trunk = release '3' 
Branches dev_1 and dev_2 are for maintenance of release '1' and release
'2'
Branch test_1 is off dev_1 and has n acl to allow only 'test' to make
merges there (ie: promote a fix from dev_1 to test_1)
A 'tested suite' is promoted from test_1 to prod_1
A CD burnt from prod_1 tags prod_1 with the CD label



There are thousands of variations though - and no 'one right answer' -
there are as many right answers as there are companies.

We cover all these in the "CM Design and CVSNT administration"  on site
course (only available to CVS Pro L2 and higher customers) and it takes
most of the day to run through it all and most participants leave with
their heads spinning (but we also usually manage to quantify the exact
'best practice' based on the presented success criteria).

Regards,


Arthur