[p4] Handling large number of manual merge conflicts
Noel.Yap at morganstanley.com
Fri Jun 11 12:12:44 PDT 2004
Hoff, Todd wrote:
>>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.
Which is why one would want to merge "regularly" -- merging either too infrequently or too often will hurt. I find the former to be much worse, though.
> 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.
For small- to medium-sized tasks, I recommend using separate clients against the main development branch. For these types of tasks, merging from the "parent" shouldn't occur too often.
> 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.
Not unless developers don't stick to "One Logical Change per Checkin".
> 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.
I agree. OTOH, if the code works, why not check it in, then do the merge and resolve? You'll have to do the latter eventually and the sooner one does it, the less the chances of conflicts.
> Then having
> to do this over and over again. There no point to it.
The point is to avoid the "Big Bang Merge" scenario.
> 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.
I don't see why all developers must be affected. What if the merge and resolve occurred in a separate client and checked in only when it works? Of course, I'm assuming these 3-day merge/resolve doesn't occur too frequently. If it does, IMHO, something's
> 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.
I'm currently doing a huge port of all our applications to a newer version of a toolset and compiler. There are about two dozen developers modifying the parent branch each day. I haven't found any major problems with merging from the parent branch on a
regular basis (between twice a day and twice a week).
Maybe the difference in our experiences lies in the branch policies. Developers in my project tend not to check in code that's highly in flux.
More information about the perforce-user