[p4] will the real change revision please step forward
John-Mason P. Shackelford
john-mason at shackelford.org
Wed Mar 23 07:59:20 PST 2005
> 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
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?
> 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.
Pearson Educational Measurement
2510 North Dodge St.
Iowa City, IA 52245
john-mason.shackelford at pearson.com
More information about the perforce-user