On Thu, Apr 19, 2012 at 12:57 PM, Julian Foad <julianf...@btopenworld.com> 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? > > 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?
I believe I answered this question already, see: http://svn.haxx.se/dev/archive-2012-03/0632.shtml If that doesn't sufficiently answer your questions let me know. As to removing support for merging into WCs with switched subtrees, let's be clear that this *does* work today (if you think otherwise please provide a use-case demonstrating what is broken). Now maybe we want to restrict these types of merges to make further improvements possible (e.g. Julian's symmetric merge work), that I won't argue against, but I want to be clear that we are making the choice to remove some existing functionality as a trade-off in implementing new functionality, rather than fixing a broken feature. Paul > - Julian
