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

Re: question about subversion 1.9 unicode normalization status

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Tue, 11 Aug 2015 21:09:15 -0400

On Tue, Aug 11, 2015 at 7:12 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Aug 11, 2015 at 05:11:10PM -0500, Dave Huang wrote:
>> On Aug 11, 2015, at 15:35, Branko Čibej <brane_at_wandisco.com> wrote:
>> >
>> > On 10.08.2015 18:46, Attila Soki wrote:
>> >> hi,
>> >>
>> >> i saw the entry "reimplement UTF-8 fuzzy conversion using utf8proc (r1511676)"
>> >> in the changelog and hoped this would be the fix for
>> >> http://subversion.tigris.org/issues/show_bug.cgi?id=2464
>> >>
>> >> but after a quick test it seems to be still broken.
>> >
>> > In my not even a bit humble opinion, what's broken is Apple's HFS, not
>> > Subversion.
>>
>> Exactly what is broken in Apple's HFS? MacOS uses one of the Unicode Normalization Forms. Perhaps it's not the same one that Windows uses, but there's nothing wrong with that. While it's unfortunate that SVN didn't handle this correctly from the start, it doesn't make it Apple's fault. Unicode 2.0 talked about normalization/canonicalization in 1996, and TR 15 has been around since about the same time--both predating SVN's development by years. Of course, most people weren't thinking about Unicode back then, and a filename was considered to be some opaque string of bytes, so I don't particularly blame SVN either. If anything, Unicode should've just declared one canonical form instead of giving options. But while HFS(+) is old and is due for an overhaul, its use of Unicode NFD isn't broken.

One can also avoid Unicode like the plague of stable programming that
it is. It's awkward enough to stabilize *any* filesystem operations
without trying to "normalize" the translations of anything that is not
internal binary compnents of a file, itself.
Received on 2015-08-12 03:09:33 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.