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

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

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2004-10-13 19:44:24 CEST

Philip Martin <philip@codematters.co.uk> writes:

> Tobias Ringström <tobias@ringstrom.mine.nu> 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
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 13 19:45:01 2004

This is an archived mail posted to the Subversion Dev mailing list.