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

Philip Martin <philip-6ttV0fGTPV0sXMjTw6Upulpr/1R2p/[email protected]> writes:

> Tobias Ringström <tobias-cF8t/[email protected]> writes:
>
>> 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.

OK, I've decided the second patch is the correct thing to do.

The first patch allowed non-UTF-8 users to commit non-ASCII symlinks,
previously such commits had failed.  Meanwhile, UTF-8 users could
commit non-ASCII symlinks both before and after my patch, so all
existing working symlinks must be UTF-8.  Allowing non-UTF-8 symlinks
is probably the wrong thing to do, as these would lead to broken links
within a UTF-8 working copy.

The second patch allows users to make symlinks within a working copy
and the links will continue to work whatever locale is used by other
checkouts.  However, it does mean that links to destinations outside
the working copy also get the link destination converted from UTF-8 to
the current locale.

-- 
Philip Martin