[p4] Handling large number of manual merge conflicts

Noel Yap Noel.Yap at morganstanley.com
Fri Jun 11 12:38:45 PDT 2004

Hoff, Todd wrote:

>>-----Original Message-----
>>From: Noel Yap [mailto:Noel.Yap at morganstanley.com]
>>Maybe the difference in our experiences lies in the branch 
>>policies.  Developers in my project tend not to check in code 
>>that's highly in flux.
> There are a lot of different projects out in the world.
> Concluding absolute rules from your project works as well
> as it does in the political realm :-)

I think I've been pretty good at qualifying my comments with "IME" :-)  Of course, I am biased that I've never worked on a space shuttle type project.  I believe some of the patterns described in Streamed Lines is meant for these kinds of projects.  OTOH, 
out of all the projects out there, how many really fall into this category percentage-wise?

> Two dozen developers, for example, is not a lot.
> Consider 100 developers making 2 changes a week on an overlapping
> set of files.  What does the change profile look like to any
> child branches?

IMHO, it doesn't really matter how many developers there are.  I don't even think it matters how many changes are going into the system.

What matters is whether your work is "stable enough" to bring in others' changes.  This applies to clients as well as to branches.

> What if just one of those changes introduces a new way
> to do something so we can fit in a certain memory limit?
> What if verifying a set of changes takes a week because there
> are many millions of dollars of scarce equipment that must be
> configured and reconfigured? What if one of those tests finds
> a very difficult to track down deadlock problem or ASIC issue?

In these cases, I would guess that the earlier the error is caught, the cheaper it is to fix.

> Keep an open mind.

I try to.

Perhaps the term "Merge Early and Often" (from Streamed Lines) is misleading.  In fact, IIRC, Streamed Lines advocates a "regular" pace for merging.  This pace depends upon a lot of things.  Whether it's thrice a day or once every three months, it is 
still, by definition, "Merge Early and Often" if it avoids the "Big Bang Merge" scenario.


More information about the perforce-user mailing list