[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-
> > how do you bring the fix forward to the current
release and all intervening ones?
> > Chuck Karish karish at well.com
> > _______________________________________________
> > 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
This message was sent using WebMail by CyberGate.
More information about the perforce-user