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_at_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_at_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)
]]]
> Looking at the spot in the test where your comment
> is, the test currently does this merge:
[...]
> 1.8.0-dev>svn.exe merge ^^/A/mu_at_11 A2\mu --accept mine-full
> --- Merging r3 through r4 into 'A2\mu':
> C A2\mu
> --- Recording mergeinfo for merge of r3 through r4 into 'A2\mu':
> G A2\mu
> Resolved conflicted state of 'A2\mu'
> --- Merging r6 through r8 into 'A2\mu':
> U A2\mu
> --- Merging r10 through r11 into 'A2\mu':
> U A2\mu
> --- Recording mergeinfo for merge of r5 through r11 into 'A2\mu':
> G A2\mu
> Summary of conflicts:
> Property conflicts: 0 remaining (and 1 already resolved)
>
> The gaps in the mergeinfo are all filled:
>
> 1.8.0-dev>svn pg svn:mergeinfo -vR A2
> Properties on 'A2':
> svn:mergeinfo
> /A:5,9
> Properties on 'A2\mu':
> svn:mergeinfo
> /A/mu:3-11
Right, but in the second half of the merge it said it was recording mergeinfo for r5, whereas for the merge from ^/A/B to A2/B, it doesn't.
> If we instead try the above merge as a directory merge targeting
> A2/mu's parent, the merge starts with r2:
I'm not sure this is relevant, since the dir merges that the test tries are all merges of the 'B' subdirectory, not of the 'A'/'A2' parent directory.
[...]
> r3 is explained by the fact that your test makes a copy of a
> mixed-revision WC to create the branch in r3:
>
>
> 1.8.0-dev>svn st -v
> 1 1 jrandom .
> 1 1 jrandom A
> 2 2 jrandom A\B
> 1 1 jrandom A\B\E
> 1 1 jrandom A\B\E\alpha
> 1 1 jrandom A\B\E\beta
> 1 1 jrandom A\B\F
> 1 1 jrandom A\B\lambda
> 1 1 jrandom A\C
> 1 1 jrandom A\D
> 1 1 jrandom A\D\G
> 1 1 jrandom A\D\G\pi
> 1 1 jrandom A\D\G\rho
> 1 1 jrandom A\D\G\tau
> 1 1 jrandom A\D\H
> 1 1 jrandom A\D\H\chi
> 1 1 jrandom A\D\H\omega
> 1 1 jrandom A\D\H\psi
> 1 1 jrandom A\D\gamma
> 2 2 jrandom A\mu
> 1 1 jrandom iota
>
> 1.8.0-dev>svn copy A A2
> A A2
>
> 1.8.0-dev>svn ci -m ""
> Adding A2
> Adding A2\B
> Adding A2\B\E
> Adding A2\B\F
> Adding A2\B\lambda
> Adding A2\mu
>
> Committed revision 3.
>
> 1.8.0-dev>svn log -v -r3
> ------------------------------------------------------------------------
> r3 | pburba | 2013-03-21 11:19:39 -0400 (Thu, 21 Mar 2013) | 1 line
> Changed paths:
> A /A2 (from /A:1)
> R /A2/B (from /A/B:2)
> R /A2/mu (from /A/mu:2)
>
> Not sure if that was an oversight or purposeful.
An oversight, but should be irrelevant. I'll tidy it up by doing an "svn up" before the copy (committed, r1459419). It makes no difference to the r5 anomaly that I'm demonstrating.
- Julian
Received on 2013-03-21 18:41:12 CET