Proposed edit to fs.py: Change 'w+' to 'wb' when copying svn stream object >> to temporary file. Update isn't needed, and the code just needs to dump >> the >> raw data into a file for the external diff to access, so no >> encoding/decoding should occur. Hence we should open the file in binary >> mode. I just tested this edit and it seems to cure the problem. >> >> It looks like this line is the same since it was originally added in >> r843330 and hasn't changed in Troy's swig-py3 branch. >> > > I've been leaning heavily on the test coverage for validating my py3 > updates. At first glance it looks like this FileDiff isn't referenced in > any existing test. I'll add a test and confirm the behavior, and then test > with your fix, unless you'd like to do so. > > Kenneth, I'm having trouble reproducing your issue. Any other hints at what might causing the trouble in your environment that you can think of? I've tried changing my locale, changing the files diffed to being utf8, all with no luck. Regardless your suggested change needs to be done on my swig-py3 branch, since it for sure needs it for Python 3, but I'd really like to understand what is going on here to make sure the issue is well and truly resolved.
Troy >> >From my initial report in the users list: >> >> <https://svn.haxx.se/users/archive-2018-01/0094.shtml> >> <https://svn.haxx.se/users/archive-2018-02/0000.shtml> >> >> I'm using mailer.py in my post-commit hook and it's throwing a Unicode >> type >> error during the diff phase. Digging through the source code, I figured >> out >> that it's happening during the creation of the two temporary files for >> diff'ing. Somehow the output file is getting opened in Unicode text mode >> but the input source (the Subversion object stream) is a raw byte stream. >> The write call fails. >> >> OS: CentOS 7.4 >> subversion-python-1.7.14-11.el7_4.x86_64 >> python-2.7.5-58.el7.x86_64 >> >> >>
