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
pgpNggW0tm_3j.pgp
Description: Digitale PGP-Signatur
