[p4] will the real change revision please step forward
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
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.
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
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