Re: Yet another Case-Insensitive File System Problem

Branko Čibej wrote:
>
> Ah, I think I see -- you're saying there was a period of time when both
> lib/unicode and lib/Unicode existed and were live. I'm sure this caused
> problems with _any_ version control system on NT and OS/X, and the only

I don't know how the Perforce client deals with it under NT. The historical
situation was that at the time this occurred, no one accessed the repository via
p4 except the committers (pumpking et al), who were all (AFAIK) running some
Unix. Everyone else got the source via a snapshot tar file; at least under NT,
tar would merge the directories silently. It appears that under OSX, tar would
automatically rename the conflicting directory (which oddly enough caused
different problems ;). Only filename conflicts were a problem.

> "solution" I can think of is to actually fiddle with the SVN repo dump
> file to rename lib/unicode to lib/unicore at the point where lib/Unicode
> was first created. This is a bit drastic, as it would mean that while
> you can check out revisions from that period on NT, you can't build the
> source anywhere any more.

Ewwwww. Not going there, thanks!

> Heh, I'd turn this around and say it was not a very nice way for the
> Perl repository admin to act when the directories with conflicting names
> were created in the first place. It's not as if systems with
> case-insensitive filenames were an obscure niche market. :-)

I fully and freely admit that this was a self-inflicted problem on the part of
the Perl pumpking! But as I said, since the majority of the developer base was
using tar-based extracts, it never caused a major problem at the time. And only
  a completely bass-ackwards OS would preserve case and yet not be able to be
case-sensitive! :~o

But, the facts on the ground are that the repository is broken for a specific
sequence of revisions on (AFAIK) only these two OS's, but works fine everywhere
else. It would be a very bad precedent to retroactively change the repository
to account for a specific client OS problem.

> The only marginally sensible way of handling this -- apart from imposing
> a project-wide naming convention that prevents such conflicts -- would
> be to add directory renaming capabilities to the SVN client.

OR, as I already suggested, give the client the ability to proceed past the
conflict (with appropriately dire warnings). It is the inability to proceed at
all, on these two platforms, without performing a completely manual checkout,
that bugs me the most. Since the subversion client can browse the repository,
regardless of case, the poor NT developer should be able to intelligently decide
what directory to exclude/include. It is only at the point of actually
instantiating the wc that the local OS has a problem.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org