[PATCH] Correct and simplify prop-change merges.

This patch fixes merge_tests.py 106.

Problem:

Merging a prop-change into the WC, the existing code regarded it as a
conflict if the property had any local modification in the WC, even if
this mod was exactly what was needed to make the working copy of the
prop value be the same as the old value of the incoming change. For
example, if you tried to merge two successive changes to the same
property into an initially clean and up-to-date WC, you would get a
conflict if you didn't commit in between the two halves. This breaks the
merge-tracking merges, and merge_tests.py 106 is an XFail test for it.

Solution:

I noticed that the logic paid great attention to the "base" version in
the WC, in ways that are rather obscure to me, whereas I would expect it
could safely ignore the "base" value altogether and just merge into the
working value. The attached patch rewrites that bit of logic using an
extremely simple condition: "if WORKING is the same as OLD then it's a
simple update, else call the resolver".

Help needed:

The only outstanding problem I know of is that merge_tests.py 41 appears
to have bogus expectations relating to whether to such a merge. I tried
briefly to fix it but have put it aside for now. If anyone can help with
this, that would be much appreciated.

Theory:

I believe we always want to perform merges into the "working" state of
the WC, without much or any regard to the "base" state. (Note that
updating the BASE during an "update" or "switch" is certainly needed, it
just doesn't impact the merge into WORKING.) Indeed, I believe the
current merge tracking implementation depends on this theory because it
splits merges into arbitrary sub-ranges. Is there any doubt? I keep
seeing old bits of code and tests that say explicitly that they expect a
conflict if there is any local mod. I intend to keep removing/fixing
such erroneous claims, unless someone points out a contrary theory.

Thanks.
- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org