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

Re: svn commit: r12676 - branches/locking/subversion/libsvn_fs_fs

From: Brian W. Fitzpatrick <fitz_at_red-bean.com>
Date: 2005-01-18 01:20:42 CET

On Jan 13, 2005, at 12:54 PM, Philip Martin wrote:

> "Brian W. Fitzpatrick" <fitz@red-bean.com> writes:
>> On Wed, 2005-01-12 at 12:01, Philip Martin wrote:
>>> "Brian W. Fitzpatrick" <fitz@red-bean.com> writes:
>>>> I'll be coming through in a pass later today to turn most of the
>>>> apr_file_FOO calls into svn_io_file_FOO calls with a nice neat
>>>> SVN_ERR
>>>> wrapper around it (which should clean up the code a good bit).
>>> One difference between apr_ and svn_io_ is that the apr functions
>>> accept paths in the system's native encoding while the svn functions
>>> accept paths in UTF-8 and converts to native before calling apr.
>>> Now,
>>> the locking paths are ASCII representations of MD5 sums are they not?
>>> Does that mean that the encoding is irrelevant?
>> Yes.
> I'm not convinced. There are at least two problems:
> 1. The restriction to ASCII only applies to the part of the path
> within the repository, the path to the repository may contain
> non-ASCII characters that require conversion.
> 2. Suppose I have LANG set to a UTF-16 encoding, then even the ASCII
> bits of the path will need to be converted.
> Thus, I think the current use of apr_ functions in lock.c is wrong.
> The paths need to undergo UTF-8 to native conversion before being
> passed to the apr_ functions, just as in the rest of Subversion. This
> applies to the apr_filepath_merge, apr_dir_make_recursive and
> apr_status calls.

You are, of course, completely correct.

This has been fixed in r12770.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 18 01:23:19 2005

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.