John wrote:
>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!!)?
>
Very badly/
> 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?
>
>
No you couldn't, but then, using "sensible" and "case-insensitive file
system" in the same sentence is a bit weird anyway.
Such filesystems do one of two things:
a) Invent a "canonical" case-folding function that "works" in all locales
b) Use whichever locale happens to be in force to do the case folding
As you observe, neither of these solutions is sensible, let alone
bullet-proof.
>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.
>
>
Right. Unfortunately, the server's consistency isn't the same as the
client's correctness. So these scripts are bound to fail on the edge cases.
>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.
>
>
Second of all, you don't want to implement this in "the core engine", as
you put it, for all the above reasons. But first of all, case
(in)sensitivity is a client problem, not a server problem; and there's
no server solution that will satisfy all clients.
>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).
>
Ohmigod, that /is/ an understatement.
>World-wide projects would probably be locale-less.
>
>Could the client lib even perform transformations of filenames to client
>locale?
>
It already does that.
> Certainly databases quite happily compare (and convert) columns of
>different collation orders (including char sets, case issues etc), so
>something similar might be possible.
>
>
I suspect databases do that (and not happily, either) because they
allowed to get themselves into this mess to begin with. I certainly do
not want to see the Subversion filesystem growing locale-awareness,
because a) it can never be 100% correct and consistent, and b) it's
already complex enough, so we really don't want to double the amount of
code.
>Just a few broad-brush questions. Sorry if any of it is dumb ;)
>
>
I don't subscribe to the idea that it's the server's job to fix
case-sensitivity problems on the client. The working-copy code should do
that.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 25 02:12:10 2005