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
Received on 2012-03-05 11:20:52 CET