Branko Čibej wrote on Thu, Feb 02, 2012 at 21:03:47 +0100: > On 02.02.2012 20:22, Peter Samuelson wrote: > > [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. > > 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. I can't envision how any of > those solutions would work all the time. > > 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
It won't. Changing the encoding increase the length (in bytes) of the string (in the dirents hash, for example), and thus change the offsets of the node-revs that are later in the file --- to which subsequent revisions, and the id's of those node-revs, refer. > (BDB would be fairly easy, modulo collisions, but I don't > think those are very likely). > > -- Brane >
