[p4] Mainline vs. Promotion (Cascade) Branching model

Marc Kwiatkowski marc at midwinter.com
Tue Dec 18 23:59:53 PST 2001

Well that is the reason for mainline branching in perforce.  But that is a deficiency
in perforce - not an inherent deficiency in cascading branches.  Sun's Teamware had excellent
support for cascading branches and it is so much nicer.  You'll never have a to do a code
freeze again to quiesce the mainline for a release branch without picking up kruft from
experimental development.  There are a lot of reasons I prefer perforce to Teamware,
but the branching model isn't one of them.

So to answer brad.holt's question, do mainline, because given perforce's inability to resolve
conflicts in branches that are more than a generation apart, cascading branches are poorly
supported at best.

Chuck Karish writes:
 > At 05:37 PM 12/18/2001 -0800, brad.holt at autodesk.com wrote:
 > >When the time comes for us to release, create our QA/Service pack branch, and merge our next version's already existing development branch back into the main, it is always a bit of a chore.  The temptation to just consider the new release's development branch to be the new main trunk is pretty strong.
 > >
 > >Please tell me why I shouldn't do this.  I'd bet there are reasons to do with future merging/common ancestors problems etc.
 > When a customer complains about a bug in a three-releases-ago product,
 > how do you bring the fix forward to the current release and all intervening ones?
 > Chuck Karish            karish at well.com           (415) 317-0182
 > _______________________________________________
 > perforce-user mailing list  -  perforce-user at perforce.com
 > http://maillist.perforce.com/mailman/listinfo/perforce-user

marc at midwinter.com

More information about the perforce-user mailing list