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.
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.
For the same reason, I'd have expected the expected output to be given
as bytes objects rather than as str objects.
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.
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),
>
>
Received on 2020-09-25 09:06:19 CEST