On 02.03.2012 09:45, Justin Erenkrantz wrote: > For branches that tend to be reintegrate targets - feature work on a > short or long-lived branch - I tend to see it's a different pattern > and doesn't usually involve cherry-picks - it's more the > sync/reintegrate model with complete merges you've discussed > throughout the rest of the document.
Don't confuse merge algorithm and CM strategy. The model you describe is reasonable, but far from universal, so the merge algorithm does need to take cherry picks (in both directions) into account. One can argue that the cherry-pick case is less common and take a two-stage approach to the implementation, leaving the more complex cherry-pick resolution for later; but I think it would be a mistake to ignore cherry picking when designing the algorithm changes themselves. Regardless of theory, actual CM strategies will reflect the capabilities of the tool used. For example, in a ClearCase shop, I'd expect cherry picking to be viewed as evil incarnate, since ClearCase is not capable of recording it. Therefore, since you can't completely avoid it in real life, the CM strategy will assume hierarchically ordered branches and merges always going in one direction through the hierarchy. DVCSes typically assume exactly the opposite. Subversion /can/ record cherry picks, and we all know what happens next. :) But that shouldn't stop Julian from figuring out how to calculate the proper sequence of virtual diff3 invocations to compensate. It might turn out that once this algorithm is known, it may even be easier to implement it in one go than to chop it up into little pieces. It's not rocket science after all, it just requires a lot of attention to details and edge cases. -- Brane
