On Thu, Apr 11, 2013 at 07:48:52PM +0200, Christoph Schulz wrote:
> >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?
Not reallt. 'svn update' is using a diff3 merge.
If you're looking for a patch tool, see 'svn patch'.
> >(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.
Well, the change says "this section of the file should not be there
anymore, get rid of it". But the section in question cannot be found.
So it does not seem unreasonable to assume that the requested change
has already happened.
I see your point though that the user might want to be alerted to the
fact that the merge does not seem to edit the expected file content.
> >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 cannot tell you because you have only provided one complete file
and two patches. To test your case with diff3 need 3 complete files
A, B, and O, where O is the original file and A and B are two
different files which are both based on O but have changed in
different ways. Patches cannot be used as input for diff3.
A nice description of diff3 is here, by the way:
http://www.cis.upenn.edu/~bcpierce/papers/diff3-short.pdf
> > - 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.
And which options has the user now when resolving the conflict?
I see the following possibilities:
1) abort the entire merge
2) accept the fact that the lines in question cannot be deleted
because they are missing
What other options do you see?
> >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.
That's unfortunate. So you're saying that if a conflict had been
signalled during the first cherry-picking merge, you would have
aborted this merge and merged the other changeset first? Would you
always know which other changeset to merge to avoid the conflict?
> Sorry, I did not talk about conflict _resolution_ but about conflict
> _detection_.
Yes, this is an important distinction. But detection only makes sense
if there is more than one way of resolution, doesn't it?
Received on 2013-04-11 20:12:37 CEST