[p4] Difference in integration behavior in 2006.2

[Leonard, William C]

I don't know for sure, but I expect it was done as a selective
integration.  That's the usual practice.

However, since the integration was resolved as a "copy from", it DOES
include revision 7, since revision 8 includes the contents of revision 7
(which includes the contents of revision 6, etc.).  I realize that the
programmer may not have explicitly SAID to include revision 7 in the
integration, but he implicitly did so when he resolved it by accepting
the source.  This is true regardless of whether revision 7 made any
actual changes to the file.

Our main question was why we started seeing this change in behavior, and
whether it's a bug or a feature?  If it was intentionally changed to be
this way, then I wouldn't want to report it as a bug.

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


-----Original Message-----
From: Stephen Vance [mailto:steve at vance.com] 
Sent: Monday, March 05, 2007 3:56 PM
To: Leonard, William C
Cc: perforce-user at perforce.com
Subject: Re: [p4] Difference in integration behavior in 2006.2

The short answer is that the algorithm was substantially rewritten in
2006.2. I don't know the exact details there.

In your example, when CL70972 was integrated, was it done as a selective
integration (e.g. @70972, at 70972) or was it done as a regular
integration? If selective, the it wouldn't have included revision 7
implicitly.

Steve

Leonard, William C wrote:
> 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/SelectSet
> Pi
> 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/Selec
> tS
> 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/SelectSet
> Pi
> 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
>
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com 
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>
>