Re: Merge policies
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 19 Apr 2012 17:57:33 +0100 (BST)
Branko Čibej wrote:
> Julian Foad wrote:
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?
This is an archived mail posted to the Subversion Dev mailing list.