[p4] Guidelines for codelines?

Matt Craighead matt.craighead at conifersystems.com
Fri Nov 21 14:37:14 PST 2008

If I'm working on a task that takes two weeks, I would commit my work in
progress no less often than once per day.  Occasionally this requires "#if
0"ing out the code, but usually not; for example, if I'm implementing a new
feature, it's often the case that the new code doesn't interfere with any
existing code.  In any event, I usually set things up so the new feature can
"go live" by changing just one line of code.  In the meantime, anyone else
interested in the feature can try activating it in their own tree by editing
that line in their local tree.

A single atomic commit that corresponds to two full weeks of work is exactly
what I called a "mass integrate" earlier in the thread -- something that I
consider a "worst practice."  This is "big bang integration" rather than
"continuous integration": all of the sudden all of the other developers see
that a huge pile of new code (often with diffs that are too complex to
understand, if we're talking about something that has been in progress for
weeks or months) has been dumped into the tree all at once.  They haven't
had visibility into this code during its development because you've been
working off in a branch that they don't watch.

The worst is when that big integrate from the dev branch to the main branch
causes a bunch of obscure regressions, i.e., it proves to have been an
ill-considered change.  (The larger the mass integrate, the more likely this
becomes.)  You'd like to back out the change from the main branch, but this
wrecks the P4 integration history -- you roll back the edits but the
integration history still thinks the changes have been integrated.

Overall, I've been burned pretty badly trying to use dev branches and would
never use them again unless I literally had no choice.  I think of branching
as a "necessary evil."

On Fri, Nov 21, 2008 at 3:22 PM, Rick Macdonald <rickmacd at shaw.ca> wrote:

> There's something I'm missing when some people say branching from the
> mainline causes more merge/integration work or problems than working
> directly in the mainline.
> If I have a task that takes me two weeks, when I'm done, I cannot submit
> my changes to the mainline until I merge the new mainline changes from
> the last two weeks unto my workspace. The required merge is initiated by
> a sync operation. I think p4win used to called this something oblique
> such as "Schedule files for resolve".
> If I have done the same two weeks of work in a branch, I have to do the
> exact same merge of the new mainline changes before I can put
> (integrate) my changes to the mainline.
> Both cases are in fact "Merge down - Copy up" activities. I don't see
> any negative difference to using the branch. There are many advantages
> to working in the branch. Many have been mentioned. One has not. If the
> work is in a workspace directly off the mainline, you can't submit the
> files until the merge/resolve is done. If the resolve goes badly, I'm
> not sure if you can undo it and get back to the state of your files
> because that state has never been submitted. Even if you can, it's still
> scary to me. When working in a branch, you can submit all you like. You
> have a record of your code changes that are safely recorded into the
> branch history before you start messing with the merge. For me, this is
> no small benefit.
> How is it any better, safer, easier working directly off the mainline? I
> don't get it.
> I must say I make changes directly to the mainline often, but only when
> the change is on a very few lines of code (often just one file), all
> done/tested/updated in a very short time (like an hour).
> Rick
>  _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user

Matt Craighead
Founder/CEO, Conifer Systems LLC

More information about the perforce-user mailing list