How do I resolve this case-sensitivity problem on Windows.

[Alexander Belchenko]

Doug Lee пишет:
> On Wed, Mar 05, 2008 at 07:53:15AM +0200, Alexander Belchenko wrote:
>> Talden ??????????:
>>> Below is a short sequence of commands that, on Windows results in the
>>> working tree always reporting removed files.  How do I fix it so that
>>> the files are removed in the branch and the working tree reports
>>> clean?
>>>
>>> NB: I know the ideal is to use "bzr mv" instead of the rename - this
>>> is a contrived example to simulate something that happened with a new
>>> vendor drop amongst thousands of files.
>> Yes, using mv is the right way for now.
> 
> Makes sense, but FYI, I have long had the problem of certain Windows
> programs "renaming" files to the case you type in their "Open"
> dialogs--e.g., if the file is Foo.txt and I type Ctrl+O for an Open
> dialog and type "foo.txt" and then save, the "F" silently becomes an
> "f."  Worse, I have one utility that plays as-yet-undetermined games
> with the case of file extensions, so that Foo.txt can suddenly become
> Foo.TXT even though I didn't type it that way.
> 
> Just a data point.

Sigh. Sigh. Sigh.
I know these "games". It's really terrible.

The real problem is that *I* don't have enough free time to write
case-insensitive filesystem supporting code. Because bzr was designed
for Linux without case-insensitiveness in mind. So adding such support
now is really not easy task. It seems easy from user point of view,
but it's really not easy from inside bzr.
And almost all core developers is Linux guys. They simply
don't affected by these "games", so it's no high priority for bzr team.
As well as line-endings support and some other windows-specific things.

>>> C:\test> ren Foo.txt foo.txt
>>>
>>> C:\test> bzr st
>>> removed:
>>>  Foo.txt
>>> unknown:
>>>  foo.txt
>>>
>>> C:\test> bzr add
>>> added foo.txt
>>>
>>> C:\test> bzr commit -m "Second"
>>> Committing to: C:/test/
>>> added foo.txt
>>> Committed revision 2.
>>>
>>> C:\test> bzr st
>>> removed:
>>>  Foo.txt
>> I believe it's the bug in commit command.
>>
>