[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/
