On Thu, 2008-09-25 at 19:19 +0100, Julian Foad wrote:
> This patch fixes merge_tests.py 106.
This version adjusts merge_tests.py 41 to expect success in its second
prop-change merge, so no failure is introduced.
I will commit this soon if no further comments.
It would be good if a mergeinfo expert could take a look at the
stripped-down mergeinfo-merging function here,
apply_single_mergeinfo_prop_change().
- Julian
> 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
Received on 2008-10-06 19:32:16 CEST