[p4] Guidelines for codelines?

Jeff A. Bowles jab at pobox.com
Fri Nov 21 07:08:10 PST 2008

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?

   -Jeff Bowles

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).

More information about the perforce-user mailing list