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
Received on 2013-04-10 19:04:16 CEST