[p4] Cherry-pick VS bulk integrate (David Ferguson)

[Greg Pan]

I would say that you are not alone in this case.

 

My shop, a relatively small one, also splits on the scheme that changes
should be propagated. The server team adopts a bulk merge approach when
a mini-milestone is reached (for example, a patch release), while the
client team (under different team lead) chooses to do the per-changelist
(something like your cherry-pick) integration. The integration direction
is from the release branch to the main. As our release cycle is short (2
- 4 wks), both bulk and per-changelist work fine. For the team running
per-changelist integration, team lead will need to do a bulk one in
order to catch any escaped fish from time to time.

 

I'm not too worried about the perception or assumption (forgive me if
it's not assumption) that a change be applied more than once. The
integration would basically mark and merge the deltas which are
relevant. As long as the snapshot of the codeline at a certain point of
time reflects the current development before or after the merge effort,
we are fine.

 

Personally I prefer bulk integration. I believe this approach emphasizes
more on the end result than the change process itself, when you see from
the perspective of the code line which receives the change propagation.

 

My 2 cents.

 

Thanks,

Greg Pan

 

 

 

 

Message: 4

Date: Fri, 8 Dec 2006 06:20:04 -0800

From: "David Ferguson" <daf at vmware.com>

Subject: Re: [p4] Cherry-pick VS bulk integrate

To: "David Weintraub" <qazwart at gmail.com>

Cc: perforce-user at perforce.com

Message-ID:

      <F9DD257BF3AA57419B08DBC55EC298FC01F56A7B at PA-EXCH02.vmware.com>

Content-Type: text/plain;     charset="us-ascii"

 

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

 

 

Greg

 

 - Software configuration management is first an attitude, second a
process, and only then a set of tools...