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.
Most Linux & UNIX hard disks have a case-sensitive file system.
Linux & Unix users routinely encounter case-insensitive filesystems when they use flash drives or SMB shares.
- The OS X HFS+ filesystem is case-insensitive by default, but can be made case-sensitive.
- All Windows filesystems are case-insensitive.
Proposals
See CaseFoldingPlan for the current plan.
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.
1. Folding Plugin
- Mercurial extensions cam customize the handling of case collisions. (Survey in process...)