Re: Merge policies

Branko Čibej wrote:

> Julian Foad wrote:
>> To get symmetric behaviour, the problem is it's freakin' hard to
>> untangle the subtree support and the mixed-rev support and the
>> missing-subtree support and everything from the basic merge algorithm
>> outline, in the existing code.  And the problem is not so much at a
>> coding level, but rather a matter of understanding what, in fact, the
>> semantics are that we're intending to implement currently.
>
> By the way, I'm all for removing support for merging into mixed-revision
> and/or switched-subtree working copies. There's too much room for
> unexpected results in these cases.

I don't necessarily disagree, but that sounds a bit unsubstantiated.  Is there too much "room for unexpected results" because you don't have a mental model of what to expect?  If I were to figure out and describe some sensible semantics and a use case, might you then change your mind?

FWIW, I have an inkling of how a mixed-rev target WC should work: it's logically very similar to having different mergeinfo on different subtrees, except that the differences are on the target side of the merge rather than the source side of the merge.  It requires some care to be sure that the parent-to-child inheritance of mergeinfo in the WC remains valid where base revision numbers differ.

That said, I can't imagine any valid reason to need to support a mixed-rev target WC.

I have thought very little about about how switched subtrees should work.  However, I *can* imagine scenarios where the user has a large chunk of WC switched, and now wants to merge something into the whole WC knowing that it won't in fact touch the switched part.  That seems like a reasonable thing to support: untouched paths being switched.  I haven't yet thought of a use case for switched paths that are touched by the merge.

Maybe Paul can help fill in some of the "how" and "why" gaps here?

- Julian
Received on 2012-04-19 18:58:10 CEST