Philip Martin wrote:
> If OS/X and Win32 use the clients' locales to do filesystem
> case-folding then your server script can only work if it uses the same
> locale. Which means that it might work in the case where all the
> clients use the same locale, but it won't work in general.
Yes, consistent locale usage is important for this and many other reasons.
>
> If the clients and server are using different OS's (which is after all
> the reason for using this script) then you have also got to worry
> about whether Linux/BSD/Windows/OSX all use the same rules when
> implementing LC_COLLATE.
That's the whole point of using locale files in the first place, isn't
it? If various OS's handle LC_COLLATE differently using the same
locales, then that should be viewed as a bug (and not our problem, per se).
> I don't see how that could be considered "making do". I suppose
> checkout could be made to do what you suggest, but if the text-base
> for the second file overwrites the text-base for the first file any
> subsequent attempt to update the first file will fail (either with a
> checksum error or because applying the first file's svndiff to second
> file's text-base produces rubbish). The result is a working copy that
> it is not safe to update.
Sorry, I meant to put a smiley there. I was being facetious due to my
frustration with being able to check out a working copy in the past due
to exactly this kind of namespace collision. The ideal case would be to
permit the client to choose one of the files to check out and then make
sure that the text-base and file are in agreement, rather than just
blocking any checkout past that file. At the very least, it should be
possible to pass '--force' and have the client code check out the
_first_ copy and warn on any subsequent files, rather than blocking
completely. The current behavior is not useful, IMHO.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 31 21:23:38 2005