Re: svn commit: r11358 - in trunk/subversion: include libsvn_subr

Philip Martin <philip-6ttV0fGTPV0sXMjTw6Upulpr/1R2p/[email protected]> Wed, 13 Oct 2004 17:38:48 +0100
Newsgroups gmane.mail.eyebrowse.devel,gmane.comp.version-control.subversion.svn
Message-ID <87r7o27euf.fsf__14028.3237248243$1097686632$gmane$org@codematters.co.uk>
Tobias Ringström <tobias-cF8t/[email protected]> writes:

> [email protected] wrote:
>
>>Author: philip
>>Date: Wed Oct 13 10:47:44 2004
>>New Revision: 11358
>>
>>
> [...]
>
>>@@ -148,6 +150,8 @@
>>  *
>>  * Set @a dest to the path that the symlink at @a path references.
>>  * Allocate the string from @a pool.
>>+ *
>>+ * Note: @a dest is not in UTF-8, it is in the native encoding.
>>  */
>> svn_error_t *svn_io_read_link (svn_string_t **dest,
>>                                const char *path,
>>
>>
> It looks like the path argument is also non-UTF-8,

Huh?  This rev makes svn_io_read_link treat path as UTF-8.

> but every other
> svn_io_ function takes UTF-8 path names. Why didn't you change these
> two functions to take and return UTF-8 paths too instead of changing
> the callers? Surely it has to be a mistake that they take and return
> non-UTF-8 paths?

My first patch did exactly that and I was going to bring the question
up, so this mail will do.

The problem with making the symlink destination UTF-8 is that it
changes the representation of the symlink in the text-base, which in
turn changes the representation in the repository.  So there are
backward compatibilty issues for repositories and working copies that
already include symlinks.  I don't know what will break.

-- 
Philip Martin