On Thu, Apr 11, 2013 at 05:29:32PM +0200, Christoph Schulz wrote: > 1) p2 depends on p1, i.e. p2 can only be applied to a.txt if p1 is > applied to a.txt before > > 2) p2 does not depend on p1, i.e. p1 and p2 are independent of each > other, i.e. we can apply p1 to a.txt first, then p2 _or_ we can > apply p2 to a.txt first, then p1; in both cases the results must be > _identical_
Why do you think Subversion treats merges just as if it was a patch tool? A patch tool does search and replace. But 'svn update' performs a 3-way merge, so it has more information (it has access to the common ancestor of the files being merged) and it can therefore make decisions that might differ from those that a patch tool might make. I don't think that cherry-picking merges can be idempotent (ie. applied in any order and still yield the same result) in the general case with the diff3 algorithm. I am assuming that you are requesting a change in Subversion's behaviour, and this is not a purely theoretical discussion. So regarding your particular use case, it would help if you gave us the following information to make sense of your feature request: - Which possible resolutions does the conflicting merge you are running into have? - Of these possible resolutions, which would you prefer in your particular scenario? Is there more than one possible resolution that you might prefer, and if so under which conditions would you pick one resolution over another? I personally don't really care about any theorical arguments you might be making about why flagging a conflict is necessary. That might be an interesting academic question but it is not very interesting when we're talking about how a tool should behave. I care about the practical implications for Subversion's users. If we are currently giving our users less choice during conflict resolution than they should have, we need to fix that. If however there is only one practical resolution for the conflict in question, then I don't see a need to change Subversion's behaviour. Does that make sense?
