[p4] Finding unintegrated changes
Jeff A. Bowles
jab at pobox.com
Tue Nov 4 13:49:17 PST 2008
When I teach Perforce classes, I give a simple rule: "fix the bug in the
codeline that will move the least, and integrate the work to the other
codelines. It is easier to modify three (3) lines to fix the bug, then
integrate to the codeline that will need ninety (90) lines to fix it, than
the other way around." (I always include the point, that ultimately, you
make the change in the "easiest" codeline and integrate / propagate from
there. "If the developer has the code available and ready to test, in
codeline 'A', then that is likely the 'right' place to make the change."
In a way, Robert's suggestion (" fix in the oldest [applicable] release
branch") is a variation of this.
On Tue, Nov 4, 2008 at 10:51 AM, Robert Cowham <robert at vizim.com> wrote:
> 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
> 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
> the rule.
> Just some thoughts
> > 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.
> perforce-user mailing list - perforce-user at perforce.com
Jeff Bowles - jeff.a.bowles at gmail.com
More information about the perforce-user