subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Shahaf <danie...@elego.de>
Subject Re: Let's discuss about unicode compositions for filenames!
Date Thu, 02 Feb 2012 20:25:16 GMT
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
> 

Mime
View raw message