[p4] will the real change revision please step forward
John-Mason P. Shackelford
john-mason at shackelford.org
Tue Mar 22 15:02:19 PST 2005
Some annoyances are so part of daily life that over time one ceases to
realize the burden they impose. Such is the case with tracking changes
in projects with large file sets and frequent branches. In order to
trigger integration accounting on a file Perforce requires a submit,
even if the file has not actually changed. This approach has the
advantage of giving us history as to when the integration was performed,
but, since it adds new revision records whether or not the file actually
changed, it obscures the file's change history.
In a project of 5,000 that branches once a month and in which only 500
files change in each branch, in a year's time we'll have 54,000
revisions which represent integrations without changes whereas only
6,000 - 18,000 revisions which actually represent changes, i.e. in this
scenario only 8% - 25% of our change history actually represents changed
If we opt to revert unchanged files during each integration we'd
eliminate the extra change history records, but at the cost of
incomplete integration accounting--Perforce would never tell us that
we'd accounted for every revision from a source branch in our target
branch. This is a costly approach given that integration accounting is
one of Perforce's chief merits over other SCM systems.
Given this background I would like to file a an enhancement request with
Perforce support to address this issue, but before I do so I'd like to
think a bit about how we'd propose to fix it and I'd like to invite
others to think with me. What exactly are we asking Perforce to change?
One line of discussion I am not particularly interested in at this time
is a discussion about whether the above scenario is actually the result
of a process problem--why so many branches and so few changes? Whether
or not this represents a process problem in our case, it is not
difficult to imagine situations in which this is quite legitimately an
issue and I'd like to see this discussion make that assumption.
== Possible Solutions ==
1. Keep an MD5 of each revision. (Doesn't this already happen?) Use
assign a letter code 'aaa', 'aab', etc. for each unique hash in all of
the related revisions being displayed in the revision graph or revision
history. Display this identification where every revision is shown so
that we can easily see the lineage of a revision which has just been
copied from branch to branch. Allow filtering (out or in) of revisions
bearing the same fingerprint so as to allow us to quickly answer the
question "on what branch was this revision of the file introduced?"
2. Others? I am all ears.
Pearson Educational Measurement
2510 North Dodge St.
Iowa City, IA 52245
john-mason.shackelford at pearson.com
More information about the perforce-user