On 2020/09/25 16:06, Daniel Shahaf wrote:
> futatuki_at_apache.org wrote on Thu, 24 Sep 2020 17:06 -0000:
>> Author: futatuki
>> Date: Thu Sep 24 17:06:39 2020
>> New Revision: 1881985
>>
>> URL: http://svn.apache.org/viewvc?rev=1881985&view=rev
>> Log:
>> Follow up to r1880192: Fix an EOL issue in test on Windows.
>>
>> * subversion/tests/cmdline/merge-tests.py
>> (merge_deleted_folder_with_mergeinfo_2): Use os.linesep instead of '\n'
>> in expected values of svn:mergeinfo.
>>
>> Modified:
>> subversion/trunk/subversion/tests/cmdline/merge_tests.py
>>
>> Modified: subversion/trunk/subversion/tests/cmdline/merge_tests.py
>> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/tests/cmdline/merge_tests.py?rev=1881985&r1=1881984&r2=1881985&view=diff
>> ==============================================================================
>> --- subversion/trunk/subversion/tests/cmdline/merge_tests.py (original)
>> +++ subversion/trunk/subversion/tests/cmdline/merge_tests.py Thu Sep 24 17:06:39 2020
>> @@ -18639,11 +18639,19 @@ def merge_deleted_folder_with_mergeinfo_
>> )
>>
>> # verify that mergeinfo is set/changed on A/D, A/D/G, A/D/G2.
>> +
>> + # NOTE: When writing out multi-line prop values in svn:* props, the
>> + # client converts to local encoding and local eol style.
>> + # Therefore, the expected output must contain the right kind of eoln
>> + # strings. That's why we use os.linesep in the tests below, not just
>> + # plain '\n'. The _last_ \n is also from the client, but it's not
>> + # part of the prop value and it doesn't get converted in the pipe.
Before answer the questions, the comment above was brougt from
prop_value_conversion() in prop_tests.py.
> I'm confused.
>
> First, if the client applies any transformation at all to property
> values, that'd be a bug. Property values are opaque octet sequences,
> just like file contents, so they must be emitted verbatim. It so
> happens that values of svn:* properties are UTF-8 with LF line endings,
> so that's what Python should see, regardless of the local encoding and
> EOL style.
I judged that EOL conversion of property values on 'svn pg' isn't bug
because this comment is found in test for it. If it is a bug,
prop_tests.py also does not test correctly.
> For the same reason, I'd have expected the expected output to be given
> as bytes objects rather than as str objects.
Those expected values are converted to bytes, just below of the diff
lines.
> Second, where is the 'last \n' that the comment refers to? I don't see
> it in the code. I wouldn't expect a trailing newline to be emitted,
> either, since svnadmin.tests.check_prop() passes --strict, which is
> documented as a deprecated alias to --no-newline.
The last line of the added comment above was extra, by mistake.
> Thanks!
>
> Daniel
>
>
>> expected_mergeinfo = [
>> ('A', ['/branch_A:3-7']),
>> - ('A/D', ['/branch_A/D:5-7\n', '/branch_B/C:1*']),
>> - ('A/D/G', ['/branch_A/D/G:5-7\n', '/branch_B/C/G:1*']),
>> - ('A/D/G2', ['/branch_A/D/G2:5-7\n', '/branch_B/C/G2:1*']),
>> + ('A/D', ['/branch_A/D:5-7'+os.linesep, '/branch_B/C:1*']),
>> + ('A/D/G', ['/branch_A/D/G:5-7'+os.linesep, '/branch_B/C/G:1*']),
>> + ('A/D/G2', ['/branch_A/D/G2:5-7'+os.linesep, '/branch_B/C/G2:1*']),
>> ]
>> for path, mergeinfo in expected_mergeinfo:
>> svntest.actions.check_prop('svn:mergeinfo', sbox.ospath(path),
<< [m.encode() for m in mergeinfo])
Cheers,
--
Yasuhito FUTATSUKI <futatuki_at_yf.bsclub.org>
Received on 2020-09-25 10:06:00 CEST