16 messages in com.perforce.perforce-userbranching question
FromSent OnAttachments
Kurt...@best.com11 May 1998 12:57 
Davi...@home.chat.net11 May 1998 14:18 
Kurt...@best.com11 May 1998 14:38 
Guid...@python.org11 May 1998 14:54 
Ping...@MIT.EDU11 May 1998 15:38 
Brad...@email.mot.comBrad_Appleton-GBDA00111 May 1998 15:45 
Step...@vance.com11 May 1998 17:14 
WesP...@xmission.com12 May 1998 00:48 
Kurt...@best.com14 May 1998 10:18 
WesP...@softweyr.com14 May 1998 10:53 
Mark...@glyphic.com14 May 1998 11:19 
Brad...@email.mot.comBrad_Appleton-GBDA00114 May 1998 11:43 
Davi...@home.chat.net14 May 1998 11:56 
Marc...@mpath.com14 May 1998 12:18 
Brad...@email.mot.comBrad_Appleton-GBDA00114 May 1998 12:30 
Davi...@home.chat.net14 May 1998 14:23 
Subject:branching question
From:Kurt...@best.com (Kurt@best.com)
Date:05/14/1998 10:18:22 AM
List:com.perforce.perforce-user

Thanks to all who responded; I got a lot of very thoughtful replies.

I read the white paper again and I think I get it now, except for one thing: I'm not convinced that I understand why "90% of SCM process is enforcing codeline promotion to compensate for the lack of a mainline". In fact, I'm not sure I get the purpose of the main- line.

In our environment, trying to keep the most active project in the mainline means that developers are creating new clients every 2-3 months, new codelines are being created more often than that, and much whining is heard.

This is what we're probably going to end up doing (Thanks for the nice ASCII graphic!):

Wes Peters - Softweyr LLC (softweyr at xmission.com) typed this ...

mainline ---+-------------------------------+----------- release_3 \ release_4 \ release_3.0 +------ release_4.0 +--- \ \ release_3.1 +------- release_4.1 +------- \ release_3.2 +---- \ release_3.3 +------------

My question about this model concerns integrations. Should integ- rations from the release_3.3 branch go to 3.2, then 3.1, touching each branch on the way to the mainline? It seems like the policy has to take into account whether the change is new development or a bug fix, and that means that our automated integration system won't work, creating the opportunity for more whining. "A tool is only as good as you use it", and if developers are spending their time whining, we're not using the tool optimally.

Thanks again!

---Kurt