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
Received on 2013-04-11 19:50:37 CEST