[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


Greetings all,

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 
files.

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.


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




More information about the perforce-user mailing list