[p4] Finding unintegrated changes

Robert Cowham robert at vizim.com
Tue Nov 4 10:51:09 PST 2008


With release branches, I tend to make the fix in the oldest release branch
currently supported and then integrate to Main (this follows Laura's Tofu
scale advice for such types of branch).

So if only R1 is out there, fix in R1 and integ to Main.

If R1 and R2 have been branched, then fix in R1, integ to R2 and then to
Main.

If R3 also, then R1 -> R2 -> R3 -> Main.

Otherwise, I assume you are always cherry picking changes on Main to integ
into the other branches, since presumably there are changes on Main that
should not go to R1 for example if you already have R2 and R3 off Main?

This approach will generally make your life easier when trying to work out
what changes are missing. Cherry picking should be the exception rather than
the rule.

Just some thoughts
Robert

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



More information about the perforce-user mailing list