[p4] Cherry-pick VS bulk integrate

Fri Dec 8 10:40:33 PST 2006

> I don't mean that.  Editing a file and putting the same change in manually is
> not what we're doing.   We're using full p4 integrate commands, we're just
> isolating the integrate at different times to a specific changeset, rather
> than a range of changesets.

Perforce doesn't handle revision skipping in integrations too well.
For example, If I've previously integrated revisions 1 to 4 from REL_1
to MAIN, and my current revision on REL_1 is Revision #10, I need to
integrate from Revision #5 on up.

I could integrate from revision #5 up to the current revision -
Revision #10. I could integrate from Revision #5 to Revision #7, and
do revisions #8 to #10 later. I could even integrate just Revision #5
by itself. Perforce doesn't seem to have a problem with that.

The problem comes when I want to integrate only Revision #7 on REL_1
to MAIN, skipping Revision #5 and Revision #6. The next time I do an
automated integration, Perforce will integrate from Revisions #5 to
the last revision -- doing the integration from Revision #7 again.

It looks like if I want to be able to have Perforce to automatically
integrate everything, I would have to manually go back and run the
integration for just revisions #5 and #6 from REL_1 to MAIN. That way,
all revisions from Revision #1 to Revision #7 would be integrated from
REL_1 to MAIN. After that, Perforce would know not to reintegrate
revisions #1 to #7 again.

On 12/8/06, David Ferguson <daf at vmware.com> wrote:
> I don't mean that.  Editing a file and putting the same change in manually is
> not what we're doing.   We're using full p4 integrate commands, we're just
> isolating the integrate at different times to a specific changeset, rather
> than a range of changesets.
>
> Assume changes 1-8 have been made to a file (or set of files) on branch A
> Somewhere there is a branch B (not necessarily a direct relation to A).
> Change 4 (in it's entirety) is integrated directly into branch B.
> At some latter time, someone tries to do a bulk merge of A into B (possibly
> through intermediary branches)...
> As far as perforce is concerned, ALL the changes 1 through 8 (from A) will be
> applied to branch  B, resulting in change 4 being applied twice.  In the vast
> majority of the cases, this isn't a problem -- The redundant code either
> shows up as identical code, or in some weird situations, a strict conflict.
> In either case, the merger can easily see that it happened and figure out
> what to do.
>
> But ... In some sufficiently complicated branching situations, we are seeing
> code duplicated without visible notification, resulting in files being
> 'safe'ly resolved without the developer realizing the issue.  I understand
> the issue (it is quite difficult to handle the multiple integrate/resolve
> cycles that would otherwise be necessary in a bulk merge), but we're trying
> to figure out a solution.
>
> In any event, the question is does anyone else mix and match this kind of
> cherry-picking and bulk merges?  Or are we alone in this usage model?
>
> -daf
>
>
> -----Original Message-----
> From: David Weintraub [mailto:qazwart at gmail.com]
> Sent: Friday, December 08, 2006 6:06 AM
> To: David Ferguson
> Cc: perforce-user at perforce.com
> Subject: Re: [p4] Cherry-pick VS bulk integrate
>
> When you say "Cherry Pick", I assume you're talking about manually editing
> one file to put the changes found in another branch into that version of the
> file.
>
> If you do that, you do confuse Perforce because there is no way for Perforce
> to know that you already put a change into a particular file.
>
> However, there is no reason why you cannot run the integration on only a
> single file. For example, if //Depot/Proj/REL_1.0/foo.cpp has a change in it
> that I also want in //Depot/Proj/MAIN/foo.cpp, I can run
> "p4 integrate" just on that one file, and Perforce handles it like a charm.
>
> You can integrate a small selected range of versions too. For example, the
> latest copy of //Depot/Proj/REL_1.0/foo.cpp is at revision #10, but I only
> want the changes up to revision #8 into foo.cpp on branch
> MAIN:
>
>     $ p4 integrate //Depot/Proj/REL_1.0/foo.cpp#1,8 //Depot/Proj/MAIN/foo.cpp
>
> That works fine too and Perforce handles that with no problems. (I don't know
> if you have to mention the range from version #1 to version  #8. You probably
> could just say //Depot/Proj/REL_1.0/foo.cpp#8).
>
> Both of these "p4 integrate" commands allow you to specify a limited
> integration, but still allows Perforce to keep track with what is being
> integrated, so you can later do a massive merge from one branch to another
> without any problems.
>
> I don't know how well Perforce handles the following situation:
>
> You've recently integrated all the changes from REL_1.0/foo.cpp between
> revisions 1 to 4. Now, you do this:
>
>    $ p4 integrate //Depot/Proj/REL_1.0/foo.cpp#7,7 //Depot/Proj/MAIN/foo.cpp
>
> That is, you only want the changes in revision #7 into MAIN, skipping
> revisions 5 and 6. I don't know what will happen when  you do this the next
> time around:
>
>    $ p4 integrate //Depot/Proj/REL_1.0/foo.cpp //Depot/Proj/MAIN/foo.cpp
>
> I believe that Perforce has problems tracking this type of integration.
>
> To recap, we told our users that even if you want a limited set of changes,
> use the "p4 integrate" command on just the files you do want to merge, and
> don't do the changes manually because you'll run into trouble later on. We
> also told our users to always integrate up to a particular revision and not
> to skip earlier revisions when they do the integration.
>
> As long as our users followed this advice, we didn't have any problems.
>
> On 12/8/06, David Ferguson <daf at vmware.com> wrote:
> > Does anybody else do both?
> > We have a  design model that uses what are basically functional
> > branches that are periodically merged down into a main integration
> > branch, and then back up into the other functional branches.
> > (development branches come off of main as late as possible).
> > However, for various reasons (with which I disagree, but oh well)
> > there are often times when people will do an explicit cherry-pick of a
> > change from one branch into a different functional branch directly,
> > not waiting for the merge to occur.
> >
> > Under certain scenarios of sufficient complexity, the final bulk merge
> > can have problems properly handling this situation and we have had
> > cases where the cherry-picked change was duplicated during the bulk
> > merge without any receiving any conflict or identical change type
> > messages.  In speaking with support about this, they have steadfastly
> > stuck to a view that people should either
> >
> > 1.  Only cherry-pick
> > 2.  Never cherry-pick
> > and are fairly adamant that almost everyone follows one of those two
> models.
> > I find that hard to believe.
> >
> > Could you drop me a line if your shop combines selective
> > cherry-picking with bulk integrations?  I'd appreciate knowing whether
> > we're really as unique as they say we are...
> >
> > -daf
> > David Ferguson
> > SCM Manager at VMware
> > _______________________________________________
> > perforce-user mailing list  -  perforce-user at perforce.com
> > http://maillist.perforce.com/mailman/listinfo/perforce-user
> >
>
>
> --
> --
> David Weintraub
> qazwart at gmail.com
>

-- 
--
David Weintraub
qazwart at gmail.com