#
#
# patch "wiki/CaseInsensitiveFilesystems.mdwn"
#  from [52dbc507db884ccbc27f3eb10caeab538f141808]
#    to [b2362ba4d45baf8e8d5785aabc7a85694bc9d305]
#
============================================================
--- wiki/CaseInsensitiveFilesystems.mdwn	52dbc507db884ccbc27f3eb10caeab538f141808
+++ wiki/CaseInsensitiveFilesystems.mdwn	b2362ba4d45baf8e8d5785aabc7a85694bc9d305
@@ -4,7 +4,7 @@ Discussion: irc logger missed it, but, i
 
 # Problems
 
-  * I have a revision with files `Potato.c` and `poTato.c`.  When I check it out, or update to it, on win32 or osx, either we silently screw things up, or we simply fail.  (Find out which!)  The latter would be better than the former, but neither is particularly appetizing.
+  * I have a revision with files `Potato.c` and `poTato.c`.  When I check it out, or update to it, on win32 or osx, we simply fail.
     * Proposed solution: extend [[MergeViaWorkingDir]] support to signal these like they were rename conflicts; this lets the user perform their checkout and then straighten things out.  This also would be applicable in the cases where there is random junk in the user's tree, that we don't want to clobber on update.
     * NB: this means that [[MergeViaWorkingDir]] needs to account for conflicts involving both versioned and unversioned files.  And whatever code detects clobbering of unversioned files needs to figure out whether the file is in fact versioned, just under a different name.
     * NB: this means we need to be able to handle n-way file name conflicts in the [[MergeViewWorkingDir]] machinery.
@@ -12,7 +12,7 @@ Discussion: irc logger missed it, but, i
 
         $ mtn add Potato.c pOtato.c poTato.c potAto.c potaTo.c potatO.c
 
-    and have monotone cheerfully add 6 files.  (I assume, have not tested this.)  This will not corrupt history (except that they then will not be able to check their tree out unless they switch to a case sensitive filesystem, see previous), but it is certainly surprising and unhelpful.
+    and have monotone cheerfully add 6 files. This will not corrupt history (except that they then will not be able to check their tree out unless they switch to a case sensitive filesystem, see previous), but it is certainly surprising and unhelpful.
     * Proposed solution: One option is to find out whether the filesystem is case-insensitive (I think the only portable way may be to write out a file to `_MTN/` and then try reading it again using a differently capitalized name?), and then write a chunk of code to make sure added files don't match each other, even with case-folded.  This requires that we know the case-folding rules, which in this i18n world is really dubious (e.g., HFS+'s [rules](http://developer.apple.com/technotes/tn/tn1150.html#[[UnicodeSubtleties]]) are guided by unicode but only fully specified by HFS+ itself).  For another option, see below.
   * "`mtn add potato.c`" when the file on disk is named `Potato.c` should make sure to add `Potato.c`, not `potato.c`.  (This might solve previous automatically.)
   * More generally, users of these filesystems expect not to have to be careful about case when specifying commands.  So, for instance, "`mtn revert potato.c`" -> "error: no such file" -- "but it's right there!  stupid program".  This applies to all commands that take filename arguments -- all restrictions, etc.