Am 19.04.2012 18:57, schrieb Julian Foad:
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.
Well, in the end one will always commit against HEAD.
But there are two use-cases of different importance
that should be supported:
* A WC is usually not at HEAD because commits don't
update unchanged nodes. On branches, the WC will
often contain the latest changes as few people work
on that branch. A WC of /trunk can be expected to be
outdated even if it was updated to HEAD shortly before
the merge.
* Mixed-rev working copies are an intermediate step
in creating arbitrary configurations via 'svn cp WC URL'.
Merging into the copy target should be semantically
identical to merging into a mixed-rev 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.
We could even be more permissive: as long as the merge
does not cross "switch boundaries" (switched / non-
switched or switched to different URL) as may allow
the merge.
This could be a somewhat typical use-case for people
using switched WCs. I would expect that these users
want to merge into those sub-trees just like they
would also 'svn up' them.
-- Stefan^2.
