Hello! Paul Burba schrieb am Wed, 10 Apr 2013 11:35:35 -0400:
Hi Christoph, If the left side of the merge doesn't equal the right side, but the right side of the merge is identical to the target, then we have long treated this as a no-op. As to why, I'm not entirely sure, but this behavior is intentional at least as far back as 1.5. There is a note in the code noting that this should more correctly be a conflict:
In my opinion, this is a shortcoming of the current implementation. From the functional point of view, this is definitely a conflict, otherwise the "patch" utility should not throw an error (as it does).
[...]svn update # files are different!Yes. But given the current (intentional) behavior in the merge of r4 above, this is what is expected.
OK, but as I said, at least _I_ did _not_ expect it to succeed. And until now you haven't succeeded in convincing me that this behaviour is correct ;-)
Let's say that r4 did raise some type of conflict. How would you resolve it?
What do you mean exactly? The file could me marked as resolved via "svn resolve" if that's what the user wants, couldn't it?
It seems quite likely that the resolution would be the same as what automatically happens today. And then the merge of r3 would work just like it does here.
That's not the point, see below.
[...] Is it that you want all three of these merges to result in the same WC state?
I was under the opinion that if I merge two or more changesets (or, more generelly speaking, apply two or more patches), the following rule applies: Either _all_ changes apply in some order(s) (and _any_ order produces the _same_ result), or _every_ change results in a conflict. So patches are either dependent on each other (in some order) or they are independent of each other (in this case, they may be applied in any order). This behaviour is safe, as it means that cherry-picking cannot "break" a branch in such a way that you cannot merge other (missing) changesets at a later point.
Obviously I was wrong, and this fundamental rule does not apply.
svn merge -r2:4 ^trunk branches/testing or svn merge -c3 ^trunk branches/testing svn merge -c4 ^trunk branches/testing or svn merge -c4 ^trunk branches/testing svn merge -c3 ^trunk branches/testing
In this particular case, I expected the merge of r4 to fail, as r4 obviously depends on r3 (it deletes the text introduced in r3). So only the first and second case should succeed, the third one should fail.
[...] Don't cherry pick the newer revisions before older revisions. Obviously from your simple reproduction script[1] there appears little need to do this, but I'm assuming you have some pressing need to do this in some more complex real world example.
In our project (a router project called "fli4l", see http://fli4l.de/), we develop new features in the trunk but associate each commit with a ticket. Later we integrate changesets of "ready" features into a separate "testing" branch, For this, a script searches for all changesets belonging to a feature and merges them into the testing branch. This works well in most cases; one corner case is that merging two changesets fails if the first changeset modifies a file and the second one removes some parent directory of the file (but this is another issue). Merging tickets in arbitrary order as long as the associated changesets do not depend on each other is crucial to this type of developing process. If SVN does not behave "safely", this may have unpleasant consequences. In our case we observed the faulty behaviour described above which made our testing branch diverge from the trunk. The problem became manifest in a subsequent merge which expected testing's files.txt to have the same contents as the one in trunk (what wasn't the case), so I had to manually fix the files.txt in the testing branch despite all changes to files.txt have been correctly merged from trunk.
Regards, Christoph Schulz
pgpg5lib0j43W.pgp
Description: Digitale PGP-Signatur
