[p4] Cherry-pick VS bulk integrate

[David Weintraub]

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