[p4] Difference in integration behavior in 2006.2

[Leonard, William C]

We recently upgraded our server from 2005.2 to 2006.2, and now we're
seeing some unexpected behavior in integrations.  We periodically run a
report to determine if there are any changes in one codeline that need
to be propagated to other codelines.  We have a fairly static
propagation path, so it's fairly easy (though not computationally cheap)
to run the report.  We're now getting reports that changes need to be
propagated from a long time ago, which previous reports (on the old
server version) did not mention.  That in itself wouldn't be bad, if the
old version were simply missing a valid case.  But we're seeing a lot of
cases that look incorrect under the new server.

I'll give a concrete example to illustrate.  Changelist 69970 created
revision 7 of the file
//depot/GTechnology/Development/Dev9.3.2EPack1/Software/Implementation/S
electSetPipe/src/selectsetpipe.cpp
by an integration from another codeline.  It is a "bookkeeping" change,
in that no actual change to the file resulted; it just records the fact
that a change in another codeline could safely be ignored when
propagating it to this codeline.  Revision 7 was never explicitly
integrated to any other codeline.

Next, changelist 70972 created revision 8 of that file with several
changes in it.  CL 70972 was integrated to
//depot/GTechnology/Development/Main/Software/Implementation/SelectSetPi
pe/src/selectsetpipe.cpp#65
in CL 71026 as a "copy from".  Consequently, revision 7 is implicitly
included in that integration, although the integration history for the
target file lists only revision 8 as the source.  (This seems like
incorrect bookkeeping to me.  If a change is integrated by accepting the
source, shouldn't that implicitly include any previous revisions not
already integrated?)

The revision 8 change was further propagated to
//depot/GTechnology/Development/Dev9.4.0/Software/Implementation/SelectS
etPipe/src/selectsetpipe.cpp#4
in CL 71132 by doing a merge.  That change was then propagated back to
//depot/GTechnology/Development/Main/Software/Implementation/SelectSetPi
pe/src/selectsetpipe.cpp#66
in CL 75272 as a "copy from".  All of the above was done with the
Perforce 2005.2 server.

Meanwhile, we've changed the order in which we propagate changes.  Files
in the //depot/GTechnology/Development/Dev9.3.2EPack1 codeline are
propagated directly to the //depot/GTechnology/Development/Dev9.4.0
codeline, and then to //depot/GTechnology/Development/Main.  The report
we run checks to make sure there are no changes in
//depot/GTechnology/Development/Dev9.3.2EPack1 that need to be promoted
to //depot/GTechnology/Development/Dev9.4.0.  It now says that revision
7 has not been integrated in that codeline.  When I do the integration,
it says there are 0 changes between source and base, and 70 changes
between target and base.  That's all believable, but why is it now
reporting this?

Technically, I guess you could say the integration history does not
indicate that revision 7 has ever been integrated.  However, the "copy
from" done in CL 71026 did implicitly include that revision; shouldn't
Perforce recognize that?

What changed in the integration algorithm that caused 2005.2 to think
this change *had* been integrated, but 2006.2 doesn't?

Thanks!

William Leonard
Executive Manager
Security, Government & Infrastructure (SG&I) Division
Intergraph Corporation
P.O. Box 6695, Huntsville, AL 35824-0695 USA 
P 1.256.730.8167   F 1.256.730.1717
bill.leonard at intergraph.com, www.intergraph.com