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
