[p4] Changelist-at-a-time VS bulk integration

[Oren Shemesh (oshemesh)]

A bit about our experience:

We used to do whole integrations (every few weeks, with the timing
synced to release schedule, testing milesotes, and such), and have found
it to be bad. Large integrations put a lot of pressure on the person
resolving cnoflicts, leading to sub-optimal decisions. If the resolved
branch fails testing (We test before submitting), hunting down the bad
resolve can be very cumbersome. All this leads to the integration being
risky (in terms of schedule), so project schedules started being
affected - leading us to a bad place.

We now use a home-brewed script that uses "integrate preview" to get a
list of all files that need integration, then sorts the relevant
changelists and integrate each one in order by itself. It does so
automatically, never integrating CLs out-of-order, and it stops whenever
there are conflicts, or it detects that a CL is not fully integrated (As
in the case where someone integrated part of the CL manually), or a
deletion is about to be integrated - in short, it stops when a human
needs to do/review the resolve. When it stops, it E-mails the author of
the original changelist, which is very scalable (It runs on a decidated
machine and a decidated workspace, which everyone is allowed to access -
but only for this purpose). It only attempts to to integrate changes
that were built and tested OK (Using our nightly build and nightly
regression), so it integrates only tested CLs.

We are very happy with this script, we use it for all our production
branches (i.e. release branches). We wrote it in order to improve the
scalability and tracability of our merges, and it seems to pay off. 

For private branches we do whole integrations, but that's OK because
there is usually no time pressure for them - it's just part of
development work.

However, to answer the original question, I would not mix whole
integrations and cherry-picked ones as a methodology on the same pair of
branches. To the best of my understanding, it should work, but I have
seen cases of weird results - specifically when indirection is involved
(probably because the selected 'base' is not always the proper one) -
and I don't want to be the one debugging Perforce.

Reagrds, Oren.

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Brad Holt
Sent: Saturday, December 09, 2006 2:19 AM
To: Ed Mack; Rick Macdonald; Perforce Users Mailing List
Subject: Re: [p4] Changelist-at-a-time VS bulk integration

Same at our end.  I just wanted to point out some plusses and minuses to
this by-change approach...

Individual changes that were done out on the branch will remain itemized
in the revision history back in main when the changes are integrated
down.  If all the changes in the branch are batched up at once and
integrated down, then it can make hunting for a particular change with
revision history or time-lapse-view trickier (it depends on the history
and resolve of the file when it returns to main).  Not a huge deal, but
some of my folks used to complain about it quite a bit.

Another advantage would be in the automation of the 2 processes.
By-change lends itself to simpler farming out of resolves to the folks
that made the changes causing the conflict.  You can just have them take
care of the integration themselves if you like.  If all your conflicts
are sitting in a single changelist, then you are stuck doing them since
they are in your workspace, and part of a larger changelist.  So you
gotta have someone come sit at your box (tricky when they are on the
other side of the globe) to do their bit or somehow farm it out
manually.

A disadvantage to by-change is that all the branch changes do not get
introduced atomically.  They will rather dribble in as they get
resolved.  If there are dependent changes, then this can cause problems.
We have had cases where an integration may have a few hundred conflicts
that need resolving which will take some time to iron out.  If this were
done as a mass integrate, then it may take a long time, but when it was
finished, it could all be brought back and would conform to a build,
label or some other benchmark on the branch which could then be tested
against.  Integration by change cannot really achieve this without some
additional policies, locking, protections, or maybe better automation
than I cobbled.

So there's good and bads either way.  Generally as the p4 guy stuck with
doing the integrations and resolves, I prefer by-change.  Others may
prefer the mass integration.


-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Ed Mack
Sent: Friday, December 08, 2006 2:07 PM
To: Rick Macdonald; Perforce Users Mailing List
Subject: Re: [p4] Changelist-at-a-time VS bulk integration

Our CM team used to do the mass merges, but now we integrate by
changelist almost exclusively.  We have a script that calls the
(undocumented) "interchanges" command to spit out the unintegrated
changes (using a list of branchspecs).  The script parses the output and
formats email notifications to the changelist owners of their list of
changelists that need integrating.

This works very well for us.

Ed

> -----Original Message-----
> From: perforce-user-bounces at perforce.com 
> [mailto:perforce-user-bounces at perforce.com] On Behalf Of Rick 
> Macdonald
> Sent: Friday, December 08, 2006 12:25 PM
> To: Perforce Users Mailing List
> Subject: [p4] Changelist-at-a-time VS bulk integration
> 
> The current thread about Cherry-picking reminds me that I 
> never heard or 
> thought about integrating one changelist at a time. I just do 
> everything 
> at once and hope for the best. Mostly it's fine. Things can get 
> complicated, but it's always been doable.
> 
> I first came across the one-at-a-time idea in Laura's book. I 
> won't give 
> an example; I'll assume folks here know what I'm referring to.
> 
> Any comments about this? Does anybody do it always? Just when 
> you think 
> you might need to? Never?
> 
> ...RickM...
> _______________________________________________
> perforce-user mailing list  -  perforce-user at perforce.com
> http://maillist.perforce.com/mailman/listinfo/perforce-user
> 

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user

_______________________________________________
perforce-user mailing list  -  perforce-user at perforce.com
http://maillist.perforce.com/mailman/listinfo/perforce-user