2012/2/3 Peter Samuelson <pe...@p12n.org>: > >> On 02.02.2012 20:22, Peter Samuelson wrote: >> > By proposing a client-only solution, I hope to avoid _all_ those >> > questions. > > [Branko Cibej] >> Can't see how that works, unless you either make the client-side >> solution optional, create a mapping table, or make name lookup on the >> server agnostic to character representation. > > Yes, I did propose a mapping table in wc.db. > > Old clients on OS X would continue to be confused; the solution is to > upgrade.
Until upgrading all clients, there are possibilities that NFD filenames are checked in to repositories. So I proposed servers change filenames to NFC before checking in to repositories. But you gave me advice it is not good as a short term solution. So I withdraw this part at this time. Please see my another post ( message id is CAN-DUMS6=ymxMYBjzDjSyQFvSQ+n4MG=pg6dihweiyw_6ag...@mail.gmail.com ) > > New clients on OS X (and elsewhere) would maintain a mapping table > between 'repository path' and 'local filesystem representation'. We > already have these two concepts, given we support non-UTF-8 client > encodings. > >> It would be nice if we could normalize paths in the repository >> without having to perform a dump/reload cycle, but I don't know how >> that would work in FSFS > > Indeed, it's a problem similar to obliterate, and carries the same risk > of invalidating every wc. This is why I don't think it's a reasonable > path to take in the short term (1.x). Well, I don't understand here. Upgrading subversion client 1.6 to 1.7 did invalidated every wc, didn't it? When I run 'svn info' with subversion 1.7 client on wc created by 1.6, I see these message and cannot use it with 1.7. svn: E155036: Please see the 'svn upgrade' command svn: E155036: Working copy '/your/wc/path/here' is too old (format 10, created by Subversion 1.6) -- )Hiroaki Nakamura) hnaka...@gmail.com
