>Branko Čibej <brane <at> xbc.nu> writes:
>>a) Invent a "canonical" case-folding function that "works" in all locales
>I guess this doesn't always work because 'A' may convert to 'a' in English,
>but the same 'A' may convert to '&' or something in another language? But
>the same unicode capital A would be used in both char sets, so
>server-folding would be partial guesswork?
>>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.
>Can you explain your thinking? My perspective is that: the server is doing
>comparisons between filenames (to check for uniquness). If it's being used
>to version control an insensitive filesystem, it needs to reflect that
>internally, or inconsistensies will result.
Heh, well, I don't see Subversion as versioning filesystems, but files.
>If it could be done in the client libs great, but how? If the server allows
>dirs 'A' and 'a' to be created, you just can't check that out any more in a
I believe that the real solution is to teach the working copy library to
always cope with such collisions. That would involve recoding or
escaping those filenames that would otherwise collide (of course the WC
must remember the original name, otherwise updates and commits would break).
This would solve the problem we have now where updates can break because
of collisions, and it would also make it easier to fix the problems that
do turn up, because you'd be able to rename the offending file on any
client, not just on the one where you committed it from.
If that were done, pre-commit checks on the server would go from "must"
to "icing on the cake", and you could live with a simpler algorithm
because false negatives wouldn't break a class of clients.
Note that client-side filename escaping wouldn't be useful just for
solving the case-collision problem; it would also solve the case where
one filesystem doesn't allow certain characters in filenames that
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Jul 25 17:20:00 2005