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

[kf...@collab.net]

So, now that that's done, my next question is:

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?

-K

kfogel@tigris.org writes:
> Log:
> Represent the current directory as "." in local path style:
> 
> * subversion/libsvn_subr/path.c
>   (svn_path_local_style): If path is "", just return "." 
> 
> * subversion/libsvn_subr/io.c
>   (io_check_path): Use svn_path_local_style.
> 
> * subversion/clients/cmdline/status.c: Include svn_path.h.
>   (svn_cl__print_status_list): Same.
> 
> * subversion/clients/cmdline/feedback.c: Include svn_path.h.
>   (svn_utf_cstring_from_utf8): Same.
> 
> * subversion/libsvn_wc/lock.c
>   (create_lock, do_open, svn_wc_adm_probe_open): Same.
> 
> Thanks to Brane for suggesting this tweak, in issue #1291.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[kf...@collab.net]

Branko Čibej <br...@xbc.nu> writes:
> Please leave the encoding and decoding separate.

Yessir.

> 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.

Ahhh -- right.

I hereby withdraw the suggestion, so quickly that you can hear the
soft *pfoomf* of air rushing in to fill the newly-created vacuum.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[Branko Čibej <br...@xbc.nu>]

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   <br...@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

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

[kf...@collab.net]

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.  Every single caller
of svn_path_internal_style() first converts the path from local
encoding to UTF8 (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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[cm...@collab.net]

kfogel@collab.net writes:

> So, now that that's done, my next question is:
> 
> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org