I've been reading through the list for case (in)sensitivity discussions, but
some stuff is missing, at least from gmane lists, so forgive me if I'm
re-asking some questions:
Is it right that an present, the repository understands nothing about case
and locale (filenames are opaque, I guess)? Everything is just UTF-8 encoded,
if it matches something already there it's an error, otherwise its fine? The
server doesn't know that (insensitive) JOHN=john because it doesn't now about
locales, and can't compare non-identical filenames.
How does a case-insensitive OS cope with differing locales on server and
workstation in this regard (hey, we're all en-GB at my place, so I don't
come up against this!!)? I assume the server locale must be the 'master'
for a directory on its disc - you couldn't sensibly have two people seeing
the same directory with different case/locale rules, could you?
The hook scripts for case currently use the server's own locale? but this
might not be the same as some clients. You can't sensibly use the clients',
for the same reason a regular network share can't - consistency.
If you were going to implement this in the core engine, how about setting a
locale on a per-repos or even per-directory basis? (I can imagine this would
be a huge job to implement, I know). Would this would solve case-folding
ambiguities? Locale would be optional. No locale would just mean the system
behaves as now.
The client lib could communicate it's own locale during server interaction,
and possibly errors thrown if they're incompatible. (maybe some tree of
compatibility could be set up, to prevent enforcement of server-locale to
all clients, which would be a pain). World-wide projects would probably be
locale-less.
Could the client lib even perform transformations of filenames to client
locale? Certainly databases quite happily compare (and convert) columns of
different collation orders (including char sets, case issues etc), so
something similar might be possible.
Just a few broad-brush questions. Sorry if any of it is dumb ;)
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 24 23:37:04 2005