[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: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-01-13 19:54:30 CET

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

Philip Martin
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 13 19:55:47 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.