[p4] Perforce integration question.

[G. Matthew Rice]

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

HTH,
-- 
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