[p4] Cherry-pick VS bulk integrate

[David Ferguson]

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