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

Re: Merge bug causes changesets to be applied although this should not be the case

From: Christoph Schulz <develop_at_kristov.de>
Date: Thu, 11 Apr 2013 19:48:52 +0200


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.


Christoph Schulz

Received on 2013-04-11 19:50:37 CEST

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