[p4] will the real change revision please step forward

[John-Mason P. Shackelford]

Robert,

> Don't understand your phrase "In order to trigger integration accounting"

I am referring to the process whereby Perforce keeps track of whether a 
revision in one branch has been integrated into another. The target 
branch gets "credit" for having accounted for changes (whether they are 
copied, merged, or ignored) in the source branch, and (unless additional 
changes are made during the integration) the source is flagged has 
having contributed integrated the change.

 > Are you talking about null integration records due to indirect 
integrations?

I don't thinks so. I am not sure I even knew about the existence of these.

 > Which version of the server are you running?

2004.2

> Can you give a more detailed example?

I'll try. I am speaking of a general problem of identifying where a 
change has actually originated. When I open a the revision graph I may 
see 500+ revisions spread across various branches, but most of these are 
copies of a single revision because when a branch or 'copy' integration 
is performed the file is submitted for the sake of the integration 
accounting though it may not represent a change on a codeline at all.

One scenario in which this manifests itself is when one has a stable 
receiving line. Changes are contributed to the receiving line from 
various branches, some files are merged in (introducing a real change) 
whereas most have not changed. For the unchanged files we can either 
accept theirs or yours, or we can just revert the integration entirely. 
If we revert the integration, we lose the ability to get a good answer 
from Perforce when we ask "have I accounted for all of the changes in my 
project branch in the stable receiving line?" If we accept theirs or 
yours we have a new change record in history of the the file on the 
stable receiving line, though no change occurred. This quickly obscures 
the history of the file since the majority of its change records will 
not actually represent a change at all.

This was certainly more problematic before -I in 2003.2 and 2004.2. In 
2004.2 only the changed files show up in the integration so most 
integration records represent an actual change. If change was made on a 
project branch and then reverted, the integ back to the stable receiving 
line would produce an integration record to account for the two 
revisions in the stable receiving line, though it wouldn't actually 
represent a change. This is a rare case and, taken alone, would probably 
not justify any change to Perforce, though it does illustrate the issue 
I am speaking of.

A scenario which is more common under the 2004, is just that of 
branching itself. In a project which branches frequently a single 
revision of a file is copied to many different locations in the depot. 
In a large project the majority of the files on a branch will change 
infrequently so the revision graph for a single file may contain show it 
at many different locations, though it changed at only one or two. 
Identifying which branches have which copy of the file is not always 
readily apparent from looking at the revision graph, it may require 
quite a bit of tracing lines back, doing diffs, etc. From the standpoint 
of this scenario, our problem may not be that integration accounting and 
file changes are submitted via the same mechanism since in an important 
sense, there is a real change taking place in the submit: a file is 
being added to a place in the depot where it did not previously exist. 
So perhaps the problem has more to do with the ability to filter 
revision history or the revision graph by the occurrence of the file in 
a particular state.


There is plenty of thinking about this topic still to do. I'd love to 
see continued discussion re: defining the problem and contemplating 
various solutions. Perhaps what we need to do is collect a list of 
revision history questions that are difficult to answer without diffs 
which server no other purpose than to identify which version of a file 
exists at a particular branch & revision number. Perhaps posting some 
illustrative revision graphs or revision histories would help too.


Thanks,


John-Mason Shackelford

Software Developer
Pearson Educational Measurement

2510 North Dodge St.
Iowa City, IA 52245
ph. 319-354-9200x6214
john-mason.shackelford at pearson.com
http://pearsonedmeasurement.com