[p4] Guidelines for codelines?
matt.craighead at conifersystems.com
Thu Nov 20 13:25:56 PST 2008
I've worked on projects where upwards of 100 people would commit code to a
single mainline on a daily or even more frequent basis. You need a good
regression testing system to make this work, but it is doable.
Instead of developing code in a branch, I find it much easier to #ifdef out
the code that isn't ready to go live yet. I find this much more convenient
than working in another branch.
There are also other, lighter-weight alternatives to branching such as
Cascade's "checkpoint" feature:
Integration is costly. Integration takes time and it can be risky (not
all integrations go smoothly). The more branches you have, the more
integrations you need to do. The longer you wait before integrating a
change, the harder the integration will get (you will have to merge with
more changes from other folks).
My general view is to use the smallest number of branches you can possibly
get away with. When in doubt, work in the same tree rather than branching.
When in doubt, cut your release branch later rather than sooner. And
instead of trying to "isolate" bad changes into development branches, focus
on developing high quality code from the start and on building more
efficient processes (such as better regression testing) that catch breaks
sooner or prevent them from happening in the first place.
Perfection may be unachievable, but the ideal to strive towards would be not
having branches at all: having all development take place in a single "main"
tree that is ready to release directly to customers at any time. Granted,
realistically release branches are necessary for any product with a QA cycle
longer than a day.
On Thu, Nov 20, 2008 at 2:30 PM, Rick Macdonald <rickmacd at shaw.ca> wrote:
> Matt, I'm responding to this not to change _your_ mind, but just for
> another viewpoint for the original poster.
> Not using development branches seems a severe way to avoid mass
> integrations. You can retain the benefit of having development branches
> without mass integrations simply by making a list of all the changelists and
> integrating them one at a time. Combine this with "Merge down - Copy Up" and
> it is not as traumatic to the mainline as doing development directly in the
> mainline can be.
> Having said that, we have always "merged down - copied up" but in 10 years
> of Perforce use in our company I've never heard of anybody needing to
> integrate one changelist at a time. I've seen several people here say they
> do, and I think Laura suggests it in her book. A lot of it depends on the
> scope of development tasks. Ours are typically relatively small and don't
> take long to do.
> I can't imagine not using branches. It's a big plus to have a different
> codeline policy for my dev branch than for the parent (mainline or
> whatever). I can checkpoint/backup changes to my dev branch even if they
> don't compile. That gives me rollback, history and diff features. Other
> programmers can sync and work with or test other people's branches.
> Matt Craighead wrote:
>> My personal recommendation is to avoid development branches. I've found
>> development branches to be a lot more trouble than they're worth. One of
>> the biggest problems is "mass integrates". I've written about this on my
>> 'One common way people end up committing large changes is the dreaded
>> integrate". That is, you have two branches, and you want to catch up the
>> one branch with all the changes made to the other branch. In a mass
>> integrate, rather than integrating each individual change over by itself,
>> you integrate all of the changes together in one big commit. Mass
>> integrates may touch hundreds or thousands of files.'
>> Also, in Perforce you can undo a bad change, but you can't simultaneously
>> roll back the integration history -- if you undo the change, the
>> history will be wrong. This makes these changes especially dangerous.
>> I would say you are better off having all development take place in the
>> On Mon, Nov 17, 2008 at 4:45 PM, steve at vance.com <steve at vance.com> wrote:
>>> The release codeline should only be for fixes to defects found in QA on
>>> release. Fixes found in other releases that need to be ported to that
>>> release qualify through integration.
>>> Think of your use of development codelines (you're really talking
>>> not just one, right?) as ways to avoid risk to the ongoing releasability
>>> and productivity of your mainline. Some people only integrate to the
>>> mainline because the only want fully qualified and reviewed changes there
>>> and branches help them implement that process.
>>> Feature that may not be done before next release? Branch it. Project with
>>> significant architectural change? Branch it. Prototype or one-off
>>> development? Branch it. Want to be able to check in without necessarily
>>> following the code quality rules on main (with good justification, of
>>> course)? Branch it.
>>> Original Message:
>>> From: Chris Helck Chris.Helck at us.icap.com
>>> Date: Mon, 17 Nov 2008 15:58:26 -0500
>>> To: perforce-user at perforce.com
>>> Subject: [p4] Guidelines for codelines?
>>> We are following the standard development, main, release model and I'm
>>> trying to create guidelines for our developers to help them figure out
>>> which codeline they should work on. My question is when can work be done
>>> directly on the main line? It seems to me the logic goes something like
>>> 1. If the change is for a specific release and the release codeline
>>> exists then the change goes on the release codeline.
>>> 2. If the change is an experiment, a large open ended change, or for an
>>> unscheduled release then it goes on a development codeline.
>>> 3. Everything else can go on the main.
>>> This isn't very crisp and it's bound to be confusing. Can someone
>>> suggest a clearer statement?
>>> Also, I understand some people use the main only for integrations.
>>> When/why is this recommended?
>>> C. Helck
>>> This communication and all information (including, but not limited to,
>>> market prices/levels and data) contained therein (the "Information") is
>>> for informational purposes only, is confidential, may be legally
>>> privileged and is the intellectual property of ICAP plc and its
>>> ("ICAP") or third parties. No confidentiality or privilege is waived or
>>> lost by any mistransmission. The Information is not, and should not
>>> be construed as, an offer, bid or solicitation in relation to any
>>> financial instrument or as an official confirmation of any transaction.
>>> The Information is not warranted, including, but not limited, as to
>>> completeness, timeliness or accuracy and is subject to change
>>> without notice. ICAP assumes no liability for use or misuse of the
>>> Information. All representations and warranties are expressly
>>> disclaimed. The Information does not necessarily reflect the views of
>>> ICAP. Access to the Information by anyone else other than the
>>> recipient is unauthorized and any disclosure, copying, distribution or
>>> any action taken or omitted to be taken in reliance on it is prohibited.
>>> you receive this message in error, please immediately delete it and all
>>> copies of it from your system, destroy any hard copies of it and
>>> notify the sender.
>>> perforce-user mailing list - perforce-user at perforce.com
>>> mail2web - Check your email from the web at
>>> perforce-user mailing list - perforce-user at perforce.com
Founder/CEO, Conifer Systems LLC
More information about the perforce-user