[p4] will the real change revision please step forward

Craig Allsop callsop at sceptre.net
Tue Mar 29 19:04:54 PST 2005


Your question is "on which branch was this revision of the file introduced?"
Do you mean on which branch/changelist was a particular line(s) of code
introduced? If so we have a simple, but manual, method of finding the
original source of any change:

1. Open a time lapse view on the interested file.
2. Find and click on the revision/line-of-code of interest in the far left
column (it marks it yellow).
3. Click on "Integrations" tab at bottom of window.
4a. If there is a file under "Sources". Right click on it and go to Step 1.
4b. If not, you've found the original change, so stop.
5. Note the change number, close the last time lapse view and instead open a
file history where you can diff against this change number or open a 'view
changelist' pane.

We have a common code base shared between different teams, each doing their
own dev branches of a team main branch. So the deepest I've had to look back
is about 6.

You can select a change in the time lapse view, now if only you could double
click on it instead and have it open another time lapse view of the source
where this change took place and take you to the same part of the file. You
could just double click your way to the original.


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of John-Mason P.
Sent: Wednesday, 23 March 2005 9:02 AM
To: perforce-user at perforce.com
Subject: [p4] will the real change revision please step forward

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 

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.

More information about the perforce-user mailing list