>>>>> On Tue, 03 Aug 2004 10:11:52 -0400, Greg Hudson wrote,
> Pretty much. Although the encoding step which failed could be avoided
> in a more perfect world, a later step would fail when we tried to find
> the repository root of the URL. We do this search by starting with the
> full path portion of the URL, and then removing trailing path elements
> until we find a repository. So we need to be able to encode the full
> URL path in the local charset.
I understand that svn_repos_find_root_path() requires local charset
encoding and also it will causes my problem. But I imagine the
following two idea may save the problem.
1. When the encoding is failed, coninue checking with shorter path
removing trailing element instead of giving up whole of searching.
2. Current svn_repos_find_root_path() checks with longest match way.
But we can take shortest match strategy, I guess.
Ex. url = /svnroot/project/trunk/dir1/dir2
check /svnroot ... not repository
check /svnroot/project ... found! it's repository
With this, the encoding restriction covers only for "/svnroot/project"
and dir1 and dir2 can be allowed as any utf-8 characters.
> As a workaround, you could set LC_CHARSET to UTF8 when running svnserve.
Thanks.
But, unfortunately, on BSD/OS 4.0.1 (old system),
apr_os_locale_charset() simply calls apr_os_default_charset()
because it doesn't have HAVE_NL_LANGINFO,
and apr_os_defalut_charset() simply returns "iso-8859-1".
So I modified apr_os_default_charset() to return "utf-8" instead of
"iso-8859-1" for workaround. I can handle kanji directory with this.
--- Regards,
Shun-ichi Goto <gotoh@taiyo.co.jp>
R&D Group, TAIYO Corp., Tokyo, JAPAN
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 3 20:16:06 2004