On Tue, Aug 11, 2015 at 7:12 PM, Stefan Sperling <s...@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 <br...@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.
