On 2011-09-13 21:16, Daniel Shahaf wrote:
> David Darj wrote on Tue, Sep 13, 2011 at 20:55:30 +0200:
>> On 2011-09-12 22:55, David Darj wrote:
>>> On 2011-09-11 21:40, Johan Corveleyn wrote:
>>>> On Mon, Sep 5, 2011 at 11:09 PM, David Darj<zid_at_alagazam.net> wrote:
>>>>> On 2011-09-02 00:02, Johan Corveleyn wrote:
>>>>>> On Tue, Aug 30, 2011 at 11:29 PM, David
>>>>>> Darj<zid_at_alagazam.net> wrote:
>>>>>>> On 2011-08-28 20:34, Johan Corveleyn wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I get a test failure of svnsync_tests.py 28: copy and reencode
>>>>>>>> non-UTF-8 svn:* props. The following error appears:
>>>>>>>>
>>>>>>>> svnsync: E720087: Can't convert string from 'ISO-8859-3' to 'UTF-8':
>>>>>>>> svnsync: E720087: 2011-01-11T20:57:24.206641Z
>>>>>>>>
>>>>>>>> See also fails.log in attachment.
>>>>>>>>
>>>>>>>> This happens on 1.7.x as well as on trunk. On Windows XP (Visual C
>>>>>>>> Express 2008).
>>>>>>>>
>>>>>>>> ISTR that this error is already there for quite some time, but I
>>>>>>>> didn't yet take the time to investigate further (and my build
>>>>>>>> environment was broken for some time). I guess it has
>>>>>>>> something to do
>>>>>>>> with r1084335, which introduced functionality to let
>>>>>>>> svnsync translate
>>>>>>>> properties that were not encoded in UTF-8.
>>>>>>>>
>>>>>>>> Is anyone else seeing this? Any ideas?
>>>>>>>>
>>>>>>> I've also seen this on my VC6 build for beta3.
>>>>>>> Didn't give it any attention then as it's "just a beta".
>>>>>>> Would be nice if anyone have any clues to the reason.
>>>>>>>
>>>>>>> /David a.k.a Alagazam
>>>>>>>
>>>>>> Any of the other Windows devs seen this? If not, could it be a
>>>>>> difference in compiler or OS, or different set of dependencies?
>>>>>>
>>>>>> Any idea what could be the cause, and what to do about it?
>>>>>>
>>>>>> FYI, I used these dependencies:
>>>>>> Httpd 2.2.19
>>>>>> Apr 1.4.5 (as included with httpd)
>>>>>> Apr-Util 1.3.12 (as included with httpd)
>>>>>> Apr-Iconv 1.2.1 (as included with httpd)
>>>>>> Neon 0.29.6
>>>>>> OpenSSL 1.0.0d
>>>>>> Serf 1.0.0
>>>>>> SQLite 3.7.7.1
>>>>>> ZLib 1.2.5
>>>>>>
>>>>>> Build environment: Visual C++ 2008 Express on Windows XP SP3.
>>>>>>
>>>>> Just for the record...here is my build environment and dependencies:
>>>>> (I've seen this on beta3,rc1 and rc2, never built trunk and
>>>>> previous betas)
>>>>>
>>>>> for beta3 and rc1:
>>>>> APR 1.4.5
>>>>> APR-util 1.3.12
>>>>> APR-Iconv 1.2.1
>>>>> BDB 4.4.20 (4.8.30 for rc2)
>>>>> libintl 0.14.1 (patched as supplied with svn 1.6.x dependencies)
>>>>> Neon 0.28.3 (0.29.6 for rc2)
>>>>> OpenSSL 0.9.8r (1.0.0d for rc2)
>>>>> Serf 0.3.0 (1.0.0 for rc2)
>>>>> sqlite 3.7.6.3 (3.7.7.1 for rc2)
>>>>> zlib 1.2.5
>>>>>
>>>>> for rc2 I've updated these:
>>>>> BDB 4.8.30
>>>>> Neon 0.29.6
>>>>> OpenSSL 1.0.0d
>>>>> Serf 1.0.0
>>>>> sqlite 3.7.7.1
>>>>>
>>>>> My build environment if WinXP SP3 fully patched, VisualStudio 6 sp 6,
>>>>> Platform SDK Feb 2003 (latest for VS6)
>>>> Hmm, at least we're both running WinXP SP3, so maybe that has
>>>> something to do with it. Maybe WinXP somehow has less language / char
>>>> encoding / ... support installed by default, which causes this to
>>>> fail.
>>>>
>>>> And now the good news: I was able to make the test succeed by enabling
>>>> "28593 (ISO 8859-3 Latin 3)" in the "Code page conversion tables" of
>>>> the OS'es "Regional and Language Options" (see Control Panel |
>>>> Regional and Language Options | Advanced).
>>>>
>>>> So in summary: this is a local failure, which can be fixed by enabling
>>>> the right "Code page conversion table" in Windows. Nothing serious to
>>>> worry about.
>>>>
>>>> Though it's still not nice that the absence of this setting causes the
>>>> test to fail, especially because it wasn't enabled by default (at
>>>> least on my system). Maybe someone on this list knows how to change
>>>> the test to make it more tolerant in this regard?
>>>>
>>> I can confirm this solution fixes the problem.
>>> I think the Win-developers signing the rc2 release all use Windows
>>> 7, maybe it have more code pages installed by default.
>>>
>>> I also took a quick look in the code and found the following
>>> "suspicious" code in libsvn_subr\utf.c (line 303) in function
>>> get_xlate_handle_node
>>>
>>> #if defined(WIN32)
>>> apr_err = svn_subr__win32_xlate_open((win32_xlate_t **)&handle,
>>> topage, frompage, pool);
>>> #else
>>> apr_err = apr_xlate_open(&handle, topage, frompage, pool);
>>> #endif
>>>
>>> Why is Windows not using apr_iconv (if available) for this conversion?
>>> (something "ivan" introduced in r865724)
>>> I will try changing this and see if solves the problem.
>>>
>>> /David
>>>
>>>
>> I just got a message from a user using my build pointing out this:
>>
>> ---
>> apr-iconv is unnecessary for a win32 subversion since 1.5.0
>> See this thread:http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=889291
>> ---
>> I guess he's right.
>>
>> Reading on Wikipedia about ISO 8859-3 it's only used for Meltese and
>> Esperanto, two quite small languages. Maybe changing the used code
>> page in the test suite to some more widely used code page, like ISO
>> 8859-1 or -15 will make the problem much smaller.
>>
> +1, is -15 installed by default on your system?
Yes "Codepage 28605 ISO 8859-15 Latin 9" is installed by default, on
both XP SP3 x86 and on x64 (booth English version with Swedish
localization).
Received on 2011-09-13 23:08:56 CEST