[p4] Guidelines for codelines?
James M Nguyen
jamesmn at yahoo.com
Fri Nov 21 12:14:53 PST 2008
Through my years of experience in build and release engineering, I've learned that there's no right or wrong way. Each method has pro's and con's. We either pay now (developing out of main) or later (integrating development branches back to main). Perforce or another source code control software is just a "tool" to help do things faster, more efficient, and less painful. Some important factors that really drive us on how to branch are our development process, release process, types of products, platforms, and customers.
For examples, (1) if one is working for a company where s/he constantly fights fires or emergencies with one or two customer(s) at a time, branches would then be all over the places, and the problem is not really in the branching methodologies. I wouldn't work for this company. (2) If one's engineering organization consistently schedules a code freeze/code completion and QA qualification start apart by only a midnight or does not allocate time and man resource for integrations at all, then minimize number of branches. While requesting new features or longer changes to be on development branches, have developers work out of main and let them resolve code conflicts before submitting them. (3) If minimizing risks is at a very top priority for an engineering organization and upper management, then branch out more and add more integration time and resource.
With all said, my suggestion is that you should put together a proposal with a few different options, present them to your development managers, QA managers, project managers, release managers, etc., and agree on one best or right methodology for your organization with full support from management team. Once that is done, you can build and automate Perforce processes to support it. Certainly there are areas on how engineers are customed to which should be changed. Developing scripts to help developers easily integrate between branches does add a lot of value and visibility.
A lot of verbage here, but that is what I've experienced as an effective way to introduce a process. Several times, someone takes a process from his/her past company and introduces it to a new company without deriving it to best fit. It looks good at first but soon be thrown out the window, not to mention that the person might lose his/her job too. Just my 2 cents!
From: Jeff A. Bowles <jab at pobox.com>
To: Matt Craighead <matt.craighead at conifersystems.com>
Cc: perforce-user at perforce.com; Rick Macdonald <rickmacd at shaw.ca>
Sent: Friday, November 21, 2008 7:08:10 AM
Subject: Re: [p4] Guidelines for codelines?
I have had to talk to new groups of perforce users, a lot, and often run
into the developer who says, "I refuse to do merges, ever."
I can't easily call that person a !#*!( incompetent who refuses to even KNOW
about a tool, in a class. Really, I cannot.
But I respond, or at least try to after I gulp rather loudly, that there is
a difference between "do not make me waste time with too many of these
merge-things" and "i have pre-decided that this is not a good model and
won't bother, because of my previous experiences with other tools."
Simple, common-sense rules that translate to "don't stupidly make more work
for yourself", can help a lot:
1. Merge early, possibly as often as every submission or every minor
2. Know how to "automerge". Know what it means. Know its limitations. Once
you know these things, use it. A lot.
3. Use the same basic approach to merging or branching as other developers
on your project.
4. Try to have the person who made the change, be the one supervising any
merge of that change. (I would not delegate the merge / integration of a
month's development work, to a flunky who knew the tool but did not know my
code. Actually, I probably might, but not if he/she is trying to merge code
from 100 developers in the same session. However, it is helpful to know
that the time that your merge-nerd spends doing your grunt-work counts
against Purgatory when they die. And this particular task hastens their
5. Of course integration is costly. But hiding not-ready-for-prime-time code
with #ifdefs is a different kind of cost, and the price is not build
headaches, but maintenance headaches in the deployed product.
you write: "Integration is costly... can be risky..." (etc)
Yeah, but are you hiring coders or engineers?
On Thu, Nov 20, 2008 at 1:25 PM, Matt Craighead <
matt.craighead at conifersystems.com> wrote:
> 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).
perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user