On Fri, Feb 11, 2011 at 7:07 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> On Thu, 2011-02-10 at 12:10 -0500, Paul Burba wrote:
>> Hi Neels (or any other tree conflict gurus),
>>
>> I know you don't have much time for Subversion these days, but if you
>> find some time in the near future could you take a look at the tests
>> you added in r879162 and combined in r879206 (this test currently
>> resides at merge_tree_conflict_tests.py 23 'replace vs. delete
>> tree-conflicts').
>>
>> I made a few tweaks to the test in r1069145 and r1069158 and it now
>> reaches the end of the test and fails.
>>
>> Currently the test does the following:
>>
>> 1) Merge a directory replacement onto a locally deleted directory
>>
>> 2) Merge a directory-replaced-with-a-file onto a locally deleted directory
>>
>> 3) Repeat the merge of a file-replaced-with-a-directory onto a locally
>> deleted directory done in #2, but this time target a subtree of #2's
>> target.
>
> This doesn't repeat anything of #2, it's completely separate.
Ah yes, I missed the fact that the merge was at depth immediates.
> #2 directory-replaced-with-a-file onto A/D/H (target A/D depth immed)
> #3 file-replaced-with-a-directory onto A/D/G/pi (target A/D/G)
>
> I would expect to see a fourth case tested too:
>
> #4 file-replaced-with-a-file onto mu
I added that in r1070629 as well as rewriting the test a bit to make
it easier to follow.
> (The test starts by calling merge_replace_setup() which sets up for all
> of these four cases.)
>
>
>> The only effect this has is the change the resulting TC type
>> from 'local delete, incoming delete upon merge' to 'local delete,
>> incoming replace upon merge'.
>
> The ideal expectation would be for all three or four cases to report
> 'local delete, incoming replace upon merge'.
>
> I don't know how close we are in implementation to being able to report
> these as incoming replacements; it might not be easy.
I'm not sure either and at the moment don't plan to go any further
than adding an associated issue for this test (issue #3806).
Thanks Julian,
Paul
>> I'm a bit foggy on what we should expect here and the test doesn't
>> have an associated issue (I was looking at this in hopes of adding
>> one).
>>
>> Here's what we are currently seeing on trunk:
>>
>> Case #1:
>>
>> >svn st -v A\B\E
>> RM + C - 4 ? A\B\E
>> > local delete, incoming delete upon merge
>
> That's quite good except it should say "incoming replace".
>
>> Case #2:
>>
>> >svn st -v A\D\H
>> D C 3 1 jrandom A\D\H
>> > local delete, incoming replace upon merge
>
> That's quite good except it should say "R" not "D".
>
>> Case #3:
>>
>> >svn st -v A\D\G
>> M 3 1 jrandom A\D\G
>> RM + C - 4 ? A\D\G\pi
>> > local delete, incoming delete upon merge
>
> That's quite good except it should say "incoming replace".
>
> Wierd that in all these cases the "D"/"R" is opposite to the message.
>
> (Also, I think status should never report "M" in the properties column
> of a "R"eplaced node. But that's a separate issue, probably unrelated
> to conflicts.)
>
> - Julian
>
>
>> I was half expecting that the incoming delete of the replacement be
>> handled first and all of these be of the 'local delete, incoming
>> delete upon merge' variety and have a local status of 'D ', but that
>> is neither what the test expects or (obviously) what the results are.
>>
>> Any insight you have into this is appreciated. If you don't have time
>> to look at this, are there any threads where this was discussed or
>> particular docs I should be looking at? The only relevant thing I
>> could find was the 'Renames and Replacements' section of
>> https://svn.apache.org/repos/asf/subversion/trunk/notes/tree-conflicts/resolution.txt,
>> but that is somewhat inconclusive.
>>
>> Thanks,
>>
>> Paul
Received on 2011-02-14 21:12:34 CET