Re: regarding issue 667: data loss??

Ben Collins-Sussman wrote:

> Is this an accurate analysis?

Precisely. This part of the issue is that the filesystem representation
can be inconsistent with the entries-file representation and in some
cases this is a harmless (from the point of view of the O/S) variation.

I thought there was a suggestion that opening the directory would return
the actual filename representation, which could be used to mediate the
behavior, rather than relying on the entries file wholey. Perhaps a
second loop only in affected O/S's which checks the directory itself for
missing files, rather than just the entries-file.

> In my ignorance of win32-ness, my instinctive proposal is to somehow
> teach libsvn_wc to be aware of its underlying filesystem. If it's a
> case-insensitive one, then it should be doing case-insensitive filename
> comparisons. If it's a case-sensitive filesystem, then do
> case-sensitive comparisons. But perhaps we've gone down this road
> before. Folks, please speak up about this.

I don't know if it has been considered, but this might be sufficient.
It still won't deal with the issue of two legitimate files in the
repository differing only in case (don't ask). I'd very much like
/that/ to be solved in such a way that the checkout isn't blocked (i.e.
the second file should throw a warning instead of an error, at least
with --force).

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