[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge policies

From: Branko Čibej <brane_at_apache.org>
Date: Thu, 19 Apr 2012 19:10:57 +0200

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
Received on 2012-04-19 19:11:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.