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

steve at vance.com steve at vance.com
Wed Dec 19 08:08:25 PST 2001

Marc is correct that Perforce's difficulty with merges 
between arbitrary branches makes the cascading model 
untenable in Perforce.

However, there is no reason to do a code freeze in the 
mainline model.  A release branch off of a mainline solves 
that problem.  The difference is that the release branches 
are all off of the mainline, rather than off of each other.

The issue with cascading branches that Chuck alludes to is 
that you can't really insert a release between two releases 
in the cascading branch model, and as much as we'd like to 
never do this, there are lots of pragmatic reasons it is 
necessary.  Better arbitrary merge support only makes it 
easier, it doesn't solve the problem.  Imagine five fixes 
that have been applied to an old version and merged 
forward, then try to insert a new version in the sequence.  
At some point you will have to deal with "catching up" with 
all of the changes that have merged into or out of the new 
release branch relative to its predecessor or successor, 
and you're still in more pain than you should knowingly 
inflict on yourself.

Rather than repeat all of the arguments against a cascading 
model here, I would recommend combing the mailing list 
archives.  There have been some very comprehensive 
discussions on the topic just in the last few months.


> 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
> 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
> 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 
>  > >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-
> -- 
> marc at midwinter.com
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-

This message was sent using WebMail by CyberGate.

More information about the perforce-user mailing list