[p4] Finding unintegrated changes
YRamasubramaniyan at webroot.com
Tue Nov 4 09:30:38 PST 2008
Thanks! I agree, the book is a fabulous resource and I found the
interchanges command in there. I checked with support and they say the
output is valid, but not to rely on the same output format in upcoming
versions of Perforce. R1, R2 etc are release branches and main is the
latest/greatest branch in our environment. That's why we submit to main
and integrate to the release branches.
I guess a better way to phrase my question is using the output of
interchanges, if I find the cl is a result of an integration (as opposed
to an edit), can I find the parent cl and see which other branches the
parent cl has been integrated into. I see more quality time with
filelog and changes -I is called for, but the script is becoming
seriously convoluted. I really like the jobs idea and will explore it
From: Rick Macdonald [mailto:rickmacd at shaw.ca]
Sent: Tuesday, November 04, 2008 8:01 AM
To: Yamuna Ramasubramaniyan
Cc: perforce-user at perforce.com
Subject: Re: [p4] Finding unintegrated changes
As Robert mentioned, Laura's book Practical Perforce is highly
recommended. Besides the interchanges command, I also use Jobs as
discussed in Chapter 8.
You could try the following:
Even after the fact, you can attach a Job to a changelist in Main. Using
jobs -i on the three R branches, it will tell you if the "fix"
associated with the Main changelist has been integrated to the other
branches. You can delete the Job and the fix when you're done, so the
whole thing can be put into a script. I think I suggested this before
(in the last few months) where I showed the commands to create and
delete the Job, but here is just the jobs command showing a change that
is in R2 but not R1:
$ p4 jobs -i -e job=xxx1234 //R1/...
$ p4 jobs -i -e job=xxx1234 //R2/...
xxx1234 on 2008/09/02 by rickm *closed* 'Temporary Job to track Main
changelist 1234 integrations.'
Yamuna Ramasubramaniyan wrote:
> I have a project which has 4 branches, Main, R1, R2 and R3. My task
> to find changes in R1 that aren't in other branches. I'm using the
> interchanges command but it doesn't help in the below case:
> * Cl #1 is submitted to main and integrated to R1 ( cl #2) and R2
> ( cl #3). I can't figure out a way to determine that cl #2 was
> submitted to R2 and not R3.
> Our dev process is that changes are submitted to Main and integrated
> R1, R2 etc. In light of this confusion, I'm tempted to abandon this
> method. What submission policy do you follow if there are multiple
> parallel development branches for a project?
> perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user