Hello!
Stefan Sperling schrieb am Thu, 11 Apr 2013 20:11:23 +0200:
>> 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.
Yes, that's exactly what I'm trying to say.
>> 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.
I don't understand. In my example I _used_ "svn merge" and,
consequently, the diff3 algorithm. It is reduced to the case where A =
O and B = A + X - X. The problem is that "A - X + X" != "A + X - X" in
this case -- the "- X" is silently ignored when tried at first.
> 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?
No other options. However, I would _like_ to have an option, which is
currently not possible, i.e. 1) cannot be achieved.
> 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?
Yes, exactly.
> Would you
> always know which other changeset to merge to avoid the conflict?
Yes, this can be decided algorithmically. Our current algorithm is a
bit "dumb" but helpful in roundabout 99% of such merge conflict
situations.
>> 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?
Personally, I don't think so. I think that there is a much more
"operational" way to define a conflict in terms of the ability or
inability to apply a changeset, and that this definition influences
the way one thinks about detecting and resolving such conflicts, and
not the other way round. A changeset (as the name say) is a set of
changes, and at the level of a single file, such a change is mainly a
combination of additions and deletions with regard to the file's
contents (ignoring property changes and the like). If, during a merge,
these additions and deletions cannot be transferred from one place to
another, a conflict occurs. Typically, such a conflict can be
automatically resolved if the operation can be performed by slightly
shifting the context (i.e. by applying a line offset) or by slightly
reducing the context (i.e. by applying a fuzz factor). What subversion
allows, though, is to resolve a "conflict" by pretending it has
performed the operation although it didn't do anything. That's odd.
I tested a bit and now I know that the other type of operation (add)
is handled equivalently, so I fear this is such a central "feature" of
Subversion (and diff3?) that it cannot be corrected: If I have
changesets in trunk of the form P1="append a line", P2="delete that
line", P3="append the same line again", then Subversion allows me to
merge P1, P3, P2 in that order into another branch and receive a file
where the append line is missing; in my view, merging of P3 should
result in a conflict because appending the same line twice is
impossible (you cannot fill a glass with water that is already full of
water).
Thank you for listening,
Christoph
Received on 2013-04-11 21:40:02 CEST