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 <qxodr...@gmail.com> > The bug fixed in svn 1.8.0,Thanks:) > > > 2013/5/24 Philip Martin <philip.mar...@wandisco.com> > >> Dongsheng Song <dongsheng.s...@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 >> > >
