[p4] Cherry-pick VS bulk integrate

Thu Dec 14 04:23:41 PST 2006

An integration bug that's reportedly fixed in the 2006.2 beta:

----------------------
#102859 * **
	    A multiple resolves into the same target file revision
	    where a subsequent resolve resulted in an 'at/accept theirs'
	    i.e. a copy would cause earlier resolves to be converted
	    into 'ignore'.  Now, if you have new clients and this
	    new server these earlier resolves may be converted
	    into 'merge' if the merge system can resonably determine
	    that no work is lost.  (Bug #7130, #18896, #17100, #2540)
----------------------

On 12/8/06, David Weintraub <qazwart at gmail.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.
>
> 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.

I have seen this behavior only with "p4 inegrate -f", in which case the
repeated integration of Revision #7 is expected.

> 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
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
>

-- 
Chuck Karish   karish at well.com   (415) 317-0182