[p4] Handling large number of manual merge conflicts
Todd.Hoff at Ciena.com
Fri Jun 11 11:55:18 PDT 2004
>I don't see this ever "being more work than it's worth"
> because, IME, "Big Bang Merges" become pretty much impossible
> to resolve correctly especially if refactoring had occurred
> on the parent branch.
Ever heard of the death of a 1000 cuts? Versus death from
a single bomb. You die either way.
Conventional wisdom is against the "big bang" merge. "not ever"
is a big statement though. For smaller development
efforts there's no issue imho. For larger features you
have to objectively balance the tradeoffs.
It depends on a lot of things: degree and types of changes on the parent,
number of developers involved, degree of change in process, retesting
effort, presence of incompatible features, etc.
Depending on the rate of change in the parent then even fairly
frequent mergings are no different than big bang merges anyway.
It's just as easy to wait and do it once correctly.
There is nothing more draining then to have code that works then have
your development interrupted while everything is fixed after a merge. Then having
to do this over and over again. There no point to it. If you
have 20 people on a feature and it takes an average of 3 days to fix
and retest, you have lost a lot of effort. If you say why does it
take 3 days? Well you don't know that unless you know the type
and degree of changes. One merge might take an hour and another
might a week to track the deadlock that was introduced somewhere.
This isn't to say you can't selectively merge code up and down,
but the repeated head banging merge cycles on code that will just
change again anyway is not useful.
More information about the perforce-user