|
Size: 1474
Comment:
|
Size: 2854
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| 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. |
If a repository contains history for "A" and then pulls a changeset containing "a", case-insensitive file systems will see this as a collision. With the result (in 1.1.2) that: |
| Line 8: | Line 7: |
| * Most Linux & UNIX hard disks have a case-sensitive file system. | * The user will be unable to create or update a working copy. * The user successfully merge and commit a merge which prevents future merges, because on a case-sensitive file system, Mercurial fails if the second parent has a case collision. If that merge is not backed out, a case-insensitive file system will have multiple unmergable heads without delving into commands that modify history (see FixingCaseCollisions if you need help doing this right now). Another easy fix (easy if you have Linux access), is to clone the repository to a case-sensitive file system, do the merge, commit, then pull the merge back to the Windows machine. Notice: can do all this on a Windows machine. You don't need multiple OS's, but it sure helps: * Most Linux & UNIX hard disks have a case-sensitive file system, but... |
| Line 10: | Line 16: |
| * The OS X HFS+ filesystem is case-insensitive by default, but can be made case-sensitive. * All Windows filesystems are case-insensitive. |
* All Windows filesystems are case-insensitive, but... * Windows users routinely encounter case-sensitive file systems when they collaborate on cross-platform projects or transfer web content to a server. * The OS X HFS+ filesystem is case-insensitive by default, but can be made case-sensitive...and can therefore experience all the exceptions mentioned above. |
| Line 15: | Line 22: |
| See CaseFoldingPlan for the current plan. | 1. See CaseFoldingPlan for the current plan. |
| Line 17: | Line 24: |
| 1. Hook mechanism | 1. Precommit Hook. The CasestopExtension works to prevent committing a potential filename collision, but it has to be enabled individually in the hgrc of every repository, user, or machine. 1. Filename Canonization Hook |
| Line 27: | Line 38: |
| 1. FixcaseExtension This extension works to coerce the case of files to match the manifest. This is a staight and simple approach that will suffice in many environments. Not sure how it handles collaborating users separately adding a file whose name case collides. |
|
| Line 28: | Line 45: |
| 1. Folding Plugin | 1. FoldPlugin |
| Line 30: | Line 47: |
| Mercurial extensions cam customize the handling of case collisions. (Survey in process...) | The FoldPlugin proposal attempts to customize the handling of case collisions. |
This page is to discuss the problem of interoperating between case-sensitive and case-insensitive filesystems.
The Problem
If a repository contains history for "A" and then pulls a changeset containing "a", case-insensitive file systems will see this as a collision. With the result (in 1.1.2) that:
- The user will be unable to create or update a working copy.
The user successfully merge and commit a merge which prevents future merges, because on a case-sensitive file system, Mercurial fails if the second parent has a case collision. If that merge is not backed out, a case-insensitive file system will have multiple unmergable heads without delving into commands that modify history (see FixingCaseCollisions if you need help doing this right now).
Another easy fix (easy if you have Linux access), is to clone the repository to a case-sensitive file system, do the merge, commit, then pull the merge back to the Windows machine.
Notice: can do all this on a Windows machine. You don't need multiple OS's, but it sure helps:
Most Linux & UNIX hard disks have a case-sensitive file system, but...
Linux & Unix users routinely encounter case-insensitive filesystems when they use flash drives or SMB shares.
- All Windows filesystems are case-insensitive, but...
- Windows users routinely encounter case-sensitive file systems when they collaborate on cross-platform projects or transfer web content to a server.
- The OS X HFS+ filesystem is case-insensitive by default, but can be made case-sensitive...and can therefore experience all the exceptions mentioned above.
Proposals
See CaseFoldingPlan for the current plan.
- Precommit Hook.
The CasestopExtension works to prevent committing a potential filename collision, but it has to be enabled individually in the hgrc of every repository, user, or machine.
- Filename Canonization Hook
- 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.
- This extension works to coerce the case of files to match the manifest. This is a staight and simple approach that will suffice in many environments. Not sure how it handles collaborating users separately adding a file whose name case collides.
The FoldPlugin proposal attempts to customize the handling of case collisions.