On Wed, Apr 10, 2013 at 1:03 PM, Christoph Schulz <deve...@kristov.de> wrote: > 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.
Yes, hence the note in the code. Even if we raise a conflict however, I'm not sure how much that will help in your example (see below). > 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? I was asking what contents of the resolved file would be; not the mechanics of resolution. Lets assume for a moment that a conflict was raised. If we resolve the conflict as a no-op, then the later merge of r3 will still (correctly) be applied and cause a divergence between trunk and the branch. This is what I mean when I said raising a conflict might not help very much in your example. >> 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. I've tried several times to parse the preceding paragraph, but I just can't make sense of what you are saying. > Obviously I was wrong, and this fundamental rule does not apply. Can you take another try at describing what this "fundamental rule" is? I think you think merge should deliver something it's never done and will likely never will...but I'm not entirely sure what you mean :-\ >> 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. -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba
