The bug found in svn 1.8.3(r1516576) again :(
E:\svnmirror>D:\tools\svn-win32-1.8.3\bin\svnadmin.exe upgrade ZmccPrj
已取得版本库锁定?请稍候；升级版本库可能需要一段时?..
E:\svnmirror>D:\tools\svn-win32-1.8.0\bin\svnadmin.exe upgrade ZmccPrj
ȡð汾
Ժ汾Ҫһʱ...
2013/6/19 QXO <qxodream_at_gmail.com>
> The bug fixed in svn 1.8.0,Thanks:)
>
>
> 2013/5/24 Philip Martin <philip.martin_at_wandisco.com>
>
>> Dongsheng Song <dongsheng.song_at_gmail.com> writes:
>>
>> >> We do call bind_textdomain_codeset if it is available so we should be
>> >> getting UTF8 translations.
>> >>
>> >
>> > For non-autotools system, e.g. Windows, user may not define
>> > HAVE_BIND_TEXTDOMAIN_CODESET.
>>
>> If you build the software with the wrong settings it may not work
>> properly. The solution is to build it with the correct settings.
>> Perhaps you can improve the Windows build.
>>
>> > Or we should call bind_textdomain_codeset as possible, and warn the
>> > user if HAVE_BIND_TEXTDOMAIN_CODESET not defined:
>> >
>> > #ifdef HAVE_BIND_TEXTDOMAIN_CODESET
>> > bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
>> > #else
>> > fprintf(sdterr, "bind_textdomain_codeset not available, or not
>> > configured. Non-UTF8 locales maybe see garbled output.\n");
>> > #endif /* HAVE_BIND_TEXTDOMAIN_CODESET */
>>
>> That error would be annoying if it was a false alarm. Perhaps we could
>> verify the correct behaviour: call gettext and check whether the
>> returned string is valid UTF8? However, we are not getting reports of
>> problems so it's probably not worth the effort. The bug that started
>> this thread is about the exact opposite: gettext was returning UTF8 and
>> the output code was failing to convert to locale encoding.
>>
>> --
>> Certified & Supported Apache Subversion Downloads:
>> http://www.wandisco.com/subversion/download
>>
>
>
Received on 2013-09-06 08:49:57 CEST