[PATCH 3 of 8] Add filesystem path to dirstate.statwalk return value

[Adrian Buehlmann]

On 05.05.2008 18:59, Matt Mackall wrote:
> On Sat, 2008-05-03 at 12:13 +0100, Paul Moore wrote:
>> 2008/5/3 Adrian Buehlmann <adrian at cadifra.com>:
>>>  I haven't noticed any side-effect case manglings in my, for example,
>>>  10+ years of Visual Studio use, but if we can keep implementation things
>>>  in Mercurial simple and fast for every day use, I'm all for it.
>> Agreed, on both counts. I've never, in my experience, seen an
>> "accidental" case change from use of a tool. But there are enough
>> reports of this happening that I'm willing to accept that it's a
>> problem for some classes of user. And clearly I'm all in favour of the
>> simplification :-)
> 
> Any program that deletes/recreates files (think editor, archiver,
> copier, compiler) based on command line arguments will either have to a)
> do the difficult job of matching command line case with on-disk case or
> b) potentially mangle case by ignoring the issue
> 
> Given that doing (a) is both slow, difficult, and mostly meaningless in
> the confines of Windows, you can be sure tha the vast majority of
> programs do (b). On the other hand, the vast majority of programs are
> rarely run from the command line and preserve case solely by virtue of
> getting passed the correct case by Explorer/Visual Studio/Visual
> SourceSafe/etc..
> 

I think your analysis is completely correct. But I'm not sure
how that explains "accidental case changes happen quite frequently
on Windows", given that tool invocations on the command line with
manually typed-in file names are rare on Windows. And even in cmd.exe (the
super dumb Windows "shell") we do have file name completion with the
tab key.

The majority of tools on Windows furthermore are not of the class of
Mercurial -- tracking changes to files and help collaborate with
UNIX people, which *is* also a delicate task with regards to folding
issues.

An example of a Windows program that does (a) is notepad. And I don't
think this is by accident or meaningless, since this is probably
one of the rare tools that indeed happen to be called on the command line.

The main big reason why Mercurial should not do (a) is that
Mercurial exactly would be hit hard on speed and program complexity.