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

Re: Proposed resolution: Standardizing on UTF-8 isn't enough

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2007-07-18 21:11:27 CEST

On 7/18/07, Thomas Singer <subversion@smartcvs.com> wrote:
> Excellent analysis! Just one additional thought: how to handle old NFD file
> names from old Mac clients when using a newer, NFC/NFD-aware server? Is
> there a possibility to abort when an non-NFC/NFD-aware client version is
> detected by the server side?

In a system which standardizes on NFC, but is generally NFC/NFD
agnostic, old clients sending NFD encoded paths shouldn't be a
problem. Nor should NFD paths in the repository, since the path will
match the one in the other NF and the commit will be rejected. Or, it
will proceed as planned when neither NF path exists.

The only reason to standardize on NFC would be not to move the NFC/NFD
problem into the Windows/Unix domain where the filesystem treats paths
as general byte sequences.

Hope that explains it?


PS: I contacted dev@apr re your other Mac problem with the locale
thing; they tend to agree the current APR behaviour regarding Darwin
filesystem encodings is incorrect and my proposal would improve the
situation. I'll keep you posted.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 18 21:10:38 2007

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.