On Wed, Apr 10, 2013 at 1:03 PM, Christoph Schulz <develop_at_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
Received on 2013-04-11 16:46:13 CEST