Hello! Stefan Sperling schrieb am Thu, 11 Apr 2013 19:32:10 +0200:
Why do you think Subversion treats merges just as if it was a patch tool?
Well, because it *is* some sort of a patch tool, when it comes to merging, isn't it?
A patch tool does search and replace.
It does not _need_ to do so. It could entirely rely on the hunk address, for example.
But 'svn update' performs a 3-way merge, so it has more information
I'm happy with that, really.
(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.
Yes, but silently ignoring the deletion of a non-existing file part is not a sound decision in my opinion.
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.
What yields the so-called diff3 algorithm in my test case? Could you elaborate on that a bit?
I am assuming that you are requesting a change in Subversion's behaviour,
I am assuming that I request the fix of a bug 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?
I am not running in a conflicting merge, that's the problem. Subversion does not recognize the conflict. So I'm afraid I don't understand your question here.
- 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 already proposed an alternative behaviour, didn't I? - Don't accept deletions if the text to be deleted does not exist. - Flag such an attempt as a conflict. - Put appropriate conflict markers as proposed in my last email.
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.
That's your view of the world, and I have to accept it. (I have a different opinion on this topic, I'm afraid.)
I care about the practical implications for Subversion's users.
I talked quite a bit about practical implications. One practical implication in our case was a defective testing branch after cherry-picking two changesets in the "wrong" order.
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.
Sorry, I did not talk about conflict _resolution_ but about conflict _detection_. This is not the same thing. You may resolve this type of conflict as you already do, I have no problems with that. However, the problem is that even with --accept=postpone no conflict is _detected_ at all.
Regards, Christoph Schulz
pgpg7tAqJqNo6.pgp
Description: Digitale PGP-Signatur
