feature or bug?

[Mark A. Flacy]

On 2008.01.03 10:19, Patrick Mézard wrote:
> Mark A. Flacy a écrit :
> > IMO, the attempts by hg to mask NTFS file naming problems was a lot  
> of
> > misguided effort that  simply pushed the problem (file collisions  
> due to
> > case) somewhere else (file name too long).  I can see why they tried
> > (host a repo on a Windows box), but lipstick on a pig still leaves  
> you
> > with a pig.
> 
> HFS+ is case-preserving too by default.

[Comments written and deleted.  You could probably guess what they would  
have been.]

> If you want interoperability, you have to handle these issues,  
> otherwise you will break repositories randomly.

Fixing these interoperability problems between filesystems is *not*  
something for the version control system to fix.

Unless you provide a virtual file system to fix it; otherwise no matter  
what you do to try to hide the problem, you can end up with repositories  
that cannot have valid working directories in the case-preserving  
environment.
> 
> > They could try some magic with hashing the file names and using the  
> hex
> > string of the hash instead of the file name, but that's not going to  
> be
> > fast and the reverse mapping would require a dictionary somewhere.
> 
> For reference, what you are talking about is proposed here:
> 
> http://www.selenic.com/mercurial/bts/issue839

*Shrugs* Well, knock yourselves out.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/naming_a_file.asp  
has all the nasty NTFS details on path length.

IMO, you would be much much better off figuring out a way to enabling a  
repository flag that enforces case-preserving commits no matter what the  
original file system is able to support.

-- 
Mark A. Flacy