Differences between revisions 4 and 5
Revision 4 as of 2006-03-06 12:07:07
Size: 1253
Editor: EricHopper
Comment:
Revision 5 as of 2006-10-23 22:37:03
Size: 1298
Editor: mpm
Comment:
Deletions are marked like this. Additions are marked like this.
Line 15: Line 15:
See CaseFoldingPlan for the current plan.

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

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.


CategoryNewFeatures

CaseFolding (last edited 2012-11-06 23:04:10 by abuehl)