Re: Let's discuss about unicode compositions for filenames!

[Hiroaki Nakamura]
> In option (2), we do n12n on all clients on all platforms, and we
> include web_dav_svn in "clients". So we convert all input paths to
> the "server encoding", which is NFC.

Indeed. But the very concept of a "server encoding" means we are
involving the server side. Which invokes a lot of difficult questions
like "what about existing 1.x clients", "what about existing checkouts"
and "what about existing repositories".

By proposing a client-only solution, I hope to avoid _all_ those
questions. (Except "what about existing checkouts" - there would be a
wc upgrade of some sort.) No recoding of existing repository paths is
necessary. In my proposal, the only recoding that is done is on the
client side, on a platform that does not support the original pathname
(e.g., OS X HFS+ with a NFC path).

> "All problems in computer science can be solved by another level of
> indirection."

Mostly true. I can't tell if you quoted that as a point of support for
my proposal, or as a point against it.

> Yes, with the mapping table, you can mangle filenames. However I
> think it is too complex for novice users. Users must care about the
> original filenames and the mangled filenames all the time.

Well, there is no need to use this same proposal to also work around
other filesystem limitations like avoiding ":" on Windows. It is just
something that becomes _possible_.

> Also you must adapt all clients to use the mapping table. That is
> whole lot of work! Maybe you would create another version control
> system.

By "all clients" I guess you mean "all Subversion client libraries".
Yes, that is the proposal. It would touch libsvn_wc and probably
libsvn_client and libsvn_subr.

> So even if Windows NTFS can have the same abstract filenames in both
> NFC and NFD simultaneously, we should avoid that, and we should only
> allow NFC filenames.

This could be done, if we wanted to go to the trouble. Or we could
just say "use a pre-commit hook," like we tell people who want to
prevent REAMDE and Reamde in a single dir. It is not the same level of
interoperability problem as the one this thread is about.

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/