[cvsnt] Merge Philosophy - Request for Comments

[John Cole]

Dianne,

  Well, that's just about exactly opposite of how we use CVS (which isn't
necessarily right or wrong).

  In our shop, the trunk is the development branch, and releases are
branches (releases are not the only branches).  Each release branch is then
locked down to read only (using 'cvs chacl -R -r branch_name default:r') and
only opened up for bug fixes.  We have a NAnt script running each morning at
3am the builds the main trunk to let everyone know that: 1) everyone's
committed code is playing nicely and 2) it's safe to do an update on your
sandboxes (if it doesn't build for you, it's your fault).

  Everyone except for people working on bug fixes develop off of the main
trunk.  The bug fix people are taught how to have multiple branches on their
machine so they can fix a bug in a branch and merge that fix to all release
branches and the trunk.

  Anyone who wants an isolated development environment creates their own
branch version or just doesn't do an update (most often the case).  We don't
have too many cases where you don't want one developer not getting changes
from another, but it does happen and we branch those people off on their own
until they are ready to merge back in.

  QA works off of a build created off of a release branch while primary
development continues on the main trunk.

  I'm amazed how well it all works :-)

  Hope this helps.  If anyone has any suggestions on how to improve the
process, I'd love to hear them.

John Cole



-----Original Message-----
From: cvsnt-bounces at cvsnt.org [mailto:cvsnt-bounces at cvsnt.org]On Behalf
Of Dianne Chen
Sent: Friday, November 05, 2004 12:59 PM
To: cvsnt at cvsnt.org
Subject: [cvsnt] Merge Philosophy - Request for Comments


Hi all-

Inexperienced with CVS, but experienced with using
other CM tools (esp. Clearcase).

I would appreciate the user community's opinions,
critiques, and suggested improvements on using CVS in
a "multiple-developers on a single program"
environment. 

I would like to set it up so that:

1) Each developer works on their own development
branch, rooted from the trunk.
2) No developer works on the trunk.
3) When the first developer is done, they merge their
work to an integration branch, also rooted from the
trunk (from the same point as #1, I bet).
4) When the second developer is done, they reconcile
the differences between their branch and the
integration branch, and then merge the result to the
integration branch.
5) Each of the remaining developers repeats step 4,
until all developers have their changes onto the
Integration branch.
6) The final contents on the Integration branch are
then rebuilt by the team lead, who tags it and
releases it to testing.
7) Once testing is complete, and the go-ahead has been
received, the contents of the integration branch are
then merged to the trunk, officially released, and the
next activity can begin.
8) Inherent in this is the desire to always have the
latest, working, approved code on the trunk.

Is this doable?

Is there a better way to isolate development activity,
but yet still provide a merge area for code
integration activity that doesn't impact the trunk?

Much, much thanks.

DC


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
_______________________________________________
cvsnt mailing list
cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt

-------------------------------------
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.