Yasuhito FUTATSUKI wrote on Fri, Oct 11, 2019 at 16:35:19 +0900:
> On 2019-10-11 06:45, Daniel Shahaf wrote:
> ...
> > From autogen.sh to 'make check', all steps pass with PYTHON=/usr/bin/python3.
>
> There were two failures in 1.11 on tests.
>
> https://lists.apache.org/thread.html/366e77c7443a0c575b47de150a2c394e1e685fde8887c805a656a33d@%3Cusers.subversion.apache.org%3E
>
> and it seems they still exist in trunk.
Sorry, my bad. I did see them in my test run too, but incorrectly determined
they were an artifact of my build environment.
> The former failure can be fixed by attached patch, fix_svnadmin_tests_patch.txt
> Index: subversion/tests/cmdline/svnadmin_tests.py
> ===================================================================
> --- subversion/tests/cmdline/svnadmin_tests.py (revision 1868264)
> +++ subversion/tests/cmdline/svnadmin_tests.py (working copy)
> @@ -3859,7 +3859,7 @@
> sbox.repo_url)
>
> dump_lines = svntest.actions.run_and_verify_dump(sbox.repo_dir)
> - assert propval + '\n' in dump_lines
> + assert propval.encode() + b'\n' in dump_lines
+1 to commit.
> The latter also can be fixed by fix_tree_conflict_tests_patch.txt
> at least so that the test can be passed on Python 3. However, from above
> stack trace, I think it is incomplete because there still exists some sort of
> confusion between bytes and str in subversion/tests/cmdline/svntest/*.py
>
> Index: subversion/tests/cmdline/tree_conflict_tests.py
> ===================================================================
> --- subversion/tests/cmdline/tree_conflict_tests.py (revision 1868264)
> +++ subversion/tests/cmdline/tree_conflict_tests.py (working copy)
> @@ -1544,7 +1544,7 @@
> contents = open(sbox.ospath('A1/B/lambda'), 'rb').readlines()
> svntest.verify.compare_and_display_lines(
> "A1/B/lambda has unexpectected contents", sbox.ospath("A1/B/lambda"),
> - [ "This is the file 'lambda'.\n", "This is more content.\n"], contents)
> + [ b"This is the file 'lambda'.\n", b"This is more content.\n"], contents)
Why do you think this is incomplete? The open() call uses mode='rb', so
«contents» will be set to an array of bytes objects, so it'll need to be
compared to an array of bytes objects. Which is to say, this patch, too, looks
correct to me.
Cheers,
Daniel
Received on 2019-10-11 19:56:12 CEST