On 19.04.2012 18:57, Julian Foad wrote:
> 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?
No, the semantics are reasonably clear. I mean unexpected results from
the user's perspective, and the sheer horror of trying to merge
svn:mergeinfo changes the repository happens to contain an
already-committed newer merge on the same branch.
-- Brane
Received on 2012-04-19 19:11:05 CEST