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 sales@march-hare.com.
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 cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook 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 cvsnt downloads at march-hare.com @CVSNT on Twitter CVSNT on Facebook http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs ------------------------------------- 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.