Release procedures with 2 working copies

Hi People, A few months ago I read someone (can't remember who, sorry) recommending the use of 2 working copies (one for the head and one for the release candidate) instead of swithicng back and forth one and the other. Asumming that is indeed a good idea, can anyone confirm the following release procedures? "boost/HEAD" is the folder containing the working copy that corresponds to the main trunk "boost/RC_X_Y_Z" is the folder containg the working copy for the current release candidate (0) Install the working copies cd boost/HEAD cvs checkout boost cd boost/RC_X_Y_Z cvs checkout -r RC_X_Y_Z boost (1) Commit local fixes in the head the to main branch (called HEAD in CVS) cd boost/HEAD cvs commit -m "Committed fixes in trunk" buggycode.hpp (2) Update the release candidate branch cd boost/RC_X_Y_Z cvs update (no need to specify the branch, as in -r RC_X_Y_Z, in this case ) (3) Merge changes in a trunk since previous merge to branch ** still in boost/RC_X_Y_Z ** cvs update -jmerged_to_RC_X_Y_Z -jHEAD buggycode.hpp --> RCS file: /cvsroot/boost/.../buggycode.hpp,v --> retrieving revision 1.4 --> retrieving revision 1.6 --> Merging differences between 1.4 and 1.6 into buggycode.hpp (4) Commit merged branch ** still in boost/RC_X_Y_Z ** cvs commit -m "Merged fix for problem xyz from trunk to branch" buggycode.hpp (5) Go back to main trunk cd boost/HEAD cvs update (no need to physically switch back to trunk adding "-A" in this case) (6) Move tag to a new merged point ** now in boost/HEAD ** cvs tag -F -c merged_to_RC_X_Y_Z buggycode.hpp (7) Repeat as needed TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/

"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
Hi People,
A few months ago I read someone (can't remember who, sorry) recommending the use of 2 working copies (one for the head and one for the release candidate) instead of swithicng back and forth one and the other.
That's what I'm doing.
Asumming that is indeed a good idea, can anyone confirm the following release procedures?
"boost/HEAD" is the folder containing the working copy that corresponds to the main trunk "boost/RC_X_Y_Z" is the folder containg the working copy for the current release candidate
(0) Install the working copies
cd boost/HEAD cvs checkout boost
cd boost cvs -d:ext:<username>@boost.cvs.sf.net:/cvsroot/boost co -d HEAD boost
cd boost/RC_X_Y_Z cvs checkout -r RC_X_Y_Z boost
cd boost cvs -d:ext:<username>@boost.cvs.sf.net:/cvsroot/boost co -rRC_X_Y_Z -d RC_X_Y_Z boost
(1) Commit local fixes in the head the to main branch (called HEAD in CVS)
cd boost/HEAD cvs commit -m "Committed fixes in trunk" buggycode.hpp
Maybe wait for a regression report to update, to make sure buggycode.hpp isn't in fact buggy on some compiler you don't have
(2) Update the release candidate branch cd boost/RC_X_Y_Z cvs update (no need to specify the branch, as in -r RC_X_Y_Z, in this case )
(3) Merge changes in a trunk since previous merge to branch ** still in boost/RC_X_Y_Z ** cvs update -jmerged_to_RC_X_Y_Z -jHEAD buggycode.hpp --> RCS file: /cvsroot/boost/.../buggycode.hpp,v --> retrieving revision 1.4 --> retrieving revision 1.6 --> Merging differences between 1.4 and 1.6 into buggycode.hpp
Note that there are 2 versions here. Someone may have committed changes to the trunk that weren't intended for the RC branch without updating merged_to_RC_X_Y_Z, so inspect the changes and make sure they're what you meant.
(4) Commit merged branch ** still in boost/RC_X_Y_Z ** cvs commit -m "Merged fix for problem xyz from trunk to branch" buggycode.hpp
(5) Go back to main trunk
cd boost/HEAD cvs update (no need to physically switch back to trunk adding "-A" in this case)
(6) Move tag to a new merged point ** now in boost/HEAD ** cvs tag -F -c merged_to_RC_X_Y_Z buggycode.hpp
(7) Repeat as needed
Looks good to me. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (2)
-
David Abrahams
-
Fernando Cacciola