[p4] Perforce integration question.
G. Matthew Rice
matt at starnix.com
Mon Feb 13 09:49:10 PST 2006
"Weintraub, David" <david.weintraub at bofasecurities.com> writes:
> 1). Create a "Development" branch and branch from Main to Development.
> 2). You do all of your work on "Development"
> 3). Once you did all of your work on "Development", you merge from Main
> to Development (what we called a Back Merge or Rebase). This puts any
> new changes on Main onto your Development branch.
> 4). You retest everything on Development, and make any necessary changes
> onto Development.
> 5). Once you're happy with the "Development" branch, you merge it back
> into "Main".
This is a good process for Perforce, too.
> Since you merged from Main #9 to Dev #4, any differences between Main #9
> and Dev #4 should be considered as if they were made based upon Main #9
> (and not just on Dev #3). That is, Dev #4 is a direct descendent of Main
> #9. When you do your merge from Dev to Main, all differences between Dev
> #4 and Main #9 should be copied to Main #10 since Main #10 is also a
> direct descendent of Main #9. Therefore, Main #10 should be a direct
> copy of Dev #4.
I think that part of your confusion is that Dev #4 is a 'direct descendant'
of Dev #3, Dev #2, etc... I don't think that merged in code from another
codeline qualifies the Main #9 as a 'direct descendant' (except for the
initial 'branches' and 'copies', I guess). Perforce generally looks along
the 'source' (their) codeline for the descendant (for the base part in the
three way merge').
> So, according to my way of thinking and if Perforce merges work the same
> way ClearCase merges do, Joseph should run "p4 resolve -as" and Perforce
> will do the merge completely automatically about 99 44/100% of the time
> with nary a complaint.
Umm, isn't it Ivory Soap that is 99 44/100% pure? You may have your stats
mixed up :)
> The only time running "p4 resolve -as" will fail is if someone manages to
> sneak in a change onto Main after Joseph does the back merge and before
> Joseph has time to merge his changes back onto Main:
I think that you are confused (or confusing us) with the term 'merge'. 'p4
integrate' aids you in pushing/pulling changes from one file (or codeline) to
another. It may mean merging but it could be other things like copy, ignore
or 'merge and edit'.
In fact, 'resolve -as' doesn't merge anything. It chooses the revision,
source (theirs) or target (yours), that has changed. And skips the
integration if that isn't the case.
> So, in conclusion (and sorry about this long post). When you merge from
> Main to Development, and then back from Development to Main, using "p4
> resolve -as" should work just the same as "p4 resolve -at" almost all of
> the time. And, the only time you will notice the difference between "p4
> resolve -as" and "p4 resolve -at" is when someone managed to sneak in
> changes onto Main that weren't originally merged into Development.
You've got it. Although, you may be understating the damage that '-at' can
do vs. '-as'. Don't use '-at'.
BTW, 'resolve -am' is the one that would merge things by hand. Although, I'd
do those ones by hand.
g. matthew rice <matt at starnix.com> starnix, toronto, ontario, ca
phone: 647.722.5301 x242 gpg id: EF9AAD20
http://www.starnix.com professional linux services & products
More information about the perforce-user