This page is to discuss the problem of interoperating between case-sensitive and case-insensitive filesystems.
The Problem
If a repository contains history for both "A" and "a", cloning it to case-insensitive filesystem will result in a collision of those history files, which will appear as corruption to verify. It will also result in collisions if both "A" and "a" appear in the same manifest.
- The standard Linux filesystems are case-sensitive, but some (like msdos) are not
- Almost all other UNIX filesystems are case-sensitive
- The OS X HFS+ filesystem is case-insensitive by default, but can be made case-sensitive
- All Windows filesystems are case-insensitive
Proposals
1. Hook mechanism
- File names should be encoded/decoded in hooks the same way as file contents can be now. For case insensitive filesystems the filename.caseinsensitive hook (or however it gets called) will be enabled by default, but you can add this to your hgrc if you want to behave the same way on a different system. This depends on extending the hook mechanism to call predefined functions, which may be generally useful for things like expanding RCS keyword strings, too.