On Thu, Mar 21, 2013 at 1:40 PM, Julian Foad <julianf...@btopenworld.com> wrote:
> Paul Burba wrote:
>
>> On Wed, Mar 20, 2013 at 4:15 PM, Julian Foad wrote:
>>>>  I have committed a complete fix, with the Summary of Conflicts as
>>>> discussed  here, in <http://svn.apache.org/r1459012>.
>>>
>>>  Remaining issues:
>>>
>>>    * There is an inconsistency with what rev ranges get recorded as merged,
>>> in a file merge vs. a dir merge -- see the comment and work-around in
>>> merge_tests.py 138.
>>
>> Hi Julian,
>>
>> I see the inconsistency, but I don't believe there is a bug (assuming
>> we are talking about the same thing -- if not please point me in the
>> right direction).
>
> Thanks for investigating, Paul.  This is what I'm talking about:
>
>     # ### Bug? The mergeinfo ranges recorded by the merge differ
>     #     slightly for a single-file merge vs. a dir merge.  That's
>     #     incidental to the purpose of this test, so we work around it
>     #     with "target == file and 'X' or 'Y'".
>     expect = expected_out_and_err(tgt_ospath,
>                                   target == file and '3-4,5-11' or '3-4,6-11',
>                                   ['3-4', '6-8,10-11'],
>                                   prop_resolved=1, expect_error=False)
>     try_merge(target, 4, [], expect, '3-11')
>
> When the target is a file, the mergeinfo notification says it's recording 
> revisions 3-4 and then 5-11; with a dir merge, it says it's recording 
> revisions 3-4 and then 6-11, *excluding* r5.
>
> I don't see the difference in recording r2, that you are showing me.  Could 
> that be an artifact of you running the test in a slightly different manner?
>
> I have just (r1459410) tweaked the test initialization (for this and several 
> other tests) to change directory to the WC before starting, so that most of 
> the local paths it prints are short and no longer start with 
> 'svn-test-work/working_copies/merge_tests-138/', to make this kind of 
> inspection easier.
>
> For the file (pasting from the test run verbose output):
> [[[
> I: ...svn merge '^/A/mu@11' A2/mu --accept mine-full --config-dir...
> I: --- Merging r3 through r4 into 'A2/mu':
> I:  C   A2/mu
> I: --- Recording mergeinfo for merge of r3 through r4 into 'A2/mu':
> I:  G   A2/mu
> I: Resolved conflicted state of 'A2/mu'
> I: --- Merging r6 through r8 into 'A2/mu':
> I:  U   A2/mu
> I: --- Merging r10 through r11 into 'A2/mu':
> I:  U   A2/mu
> I: --- Recording mergeinfo for merge of r5 through r11 into 'A2/mu':
> I:  G   A2/mu
> I: Summary of conflicts:
> I:   Property conflicts: 0 remaining (and 1 already resolved)
> ]]]
>
> For the dir:
> [[[
> I: ...svn merge '^/A/B@11' A2/B --accept mine-full --config-dir...
> I: --- Merging r3 through r4 into 'A2/B':
> I:  C   A2/B
> I: --- Recording mergeinfo for merge of r3 through r4 into 'A2/B':
> I:  G   A2/B
> I: Resolved conflicted state of 'A2/B'
> I: --- Merging r6 through r8 into 'A2/B':
> I:  U   A2/B
> I: --- Merging r10 through r11 into 'A2/B':
> I:  U   A2/B
> I: --- Recording mergeinfo for merge of r6 through r11 into 'A2/B':
> I:  G   A2/B
> I: Summary of conflicts:
> I:   Property conflicts: 0 remaining (and 1 already resolved)
> ]]]

Ok, I initially misunderstood the comment.  r1459895 fixes this.

-- 
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba

Reply via email to