----- Original Message -----
> From: Branko Čibej <brane_at_apache.org>
> To: dev_at_subversion.apache.org
> Cc:
> Sent: Thursday, 19 April 2012, 18:10
> Subject: Re: Merge policies
>
> 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.
But the repo already having a committed merge later on the same branch is not specific to a mixed-rev WC. That can happen any your WC isn't at HEAD. Unless you've locked the branch against further commits and updated to head. Is that what we should be checking for, instead?
- Julian
Received on 2012-04-19 19:22:18 CEST