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