[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 5912 - in trunk/subversion: clients/cmdline libsvn_subr libsvn_wc

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-05-13 21:29:33 CEST

kfogel@collab.net wrote:

>cmpilato@collab.net writes:
>
>
>>>Should svn_path_local_style() always convert the incoming UTF8 path to
>>>native encoding? I think that would be appropriate for all callers,
>>>and it would smallify some code... Thoughts?
>>>
>>>
>>Does svn_path_internal_style() do the opposite conversion? I think
>>there's benefit to trying to keep these two functions symmetrical.
>>
>>
>
>Good point. It doesn't right now, but it could.
>
It could, but it should not.

> Every single caller
>of svn_path_internal_style() first converts the path from local
>encoding to UTF8
>
Not necessarily. I have Plans to finally fix issue #872 (which I
reopened because of Win9x problems and, more importantly, potential
svnserve problems). That will introduce new encoding types besides local
and UTF8 (namely, console input and console output).

> (with the possible exception of one conditional
>branch in svn_config__win_config_path, which could be dealt with).
>
>So the functions could still be symmetrical, and take care of our
>encoding/decoding needs at the same time they do the style change.
>
>
Please leave the encoding and decoding separate.

Oh, and there's another reason: svn_path_local_style needs to be called
on all error message parameters that represent files or paths. But error
message have to remain in UTF8 untill they meet the handler.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 13 21:31:14 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.