On Thu, Apr 11, 2013 at 05:29:32PM +0200, Christoph Schulz wrote:
> 1) p2 depends on p1, i.e. p2 can only be applied to a.txt if p1 is
> applied to a.txt before
>
> 2) p2 does not depend on p1, i.e. p1 and p2 are independent of each
> other, i.e. we can apply p1 to a.txt first, then p2 _or_ we can
> apply p2 to a.txt first, then p1; in both cases the results must be
> _identical_
Why do you think Subversion treats merges just as if it was a patch tool?
A patch tool does search and replace.
But 'svn update' performs a 3-way merge, so it has more information
(it has access to the common ancestor of the files being merged) and
it can therefore make decisions that might differ from those that a
patch tool might make.
I don't think that cherry-picking merges can be idempotent (ie. applied
in any order and still yield the same result) in the general case with
the diff3 algorithm.
I am assuming that you are requesting a change in Subversion's behaviour,
and this is not a purely theoretical discussion. So regarding your particular
use case, it would help if you gave us the following information to make
sense of your feature request:
- Which possible resolutions does the conflicting merge you are
running into have?
- Of these possible resolutions, which would you prefer in your
particular scenario? Is there more than one possible resolution
that you might prefer, and if so under which conditions would you
pick one resolution over another?
I personally don't really care about any theorical arguments you
might be making about why flagging a conflict is necessary. That might
be an interesting academic question but it is not very interesting
when we're talking about how a tool should behave.
I care about the practical implications for Subversion's users.
If we are currently giving our users less choice during conflict
resolution than they should have, we need to fix that. If however
there is only one practical resolution for the conflict in question,
then I don't see a need to change Subversion's behaviour.
Does that make sense?
Received on 2013-04-11 19:32:46 CEST