case sensitivity on Windows

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Hammond wrote:
> I'm baaaaack.... :)
> 
> Martin writes:
> 
>> Yes, there's hope of help from other bzr developers.  Maybe a good
>> place to begin would be with a kind of doctest-ish description of what
>> mappings are meant to occur and where.
> 
> So I wrote:
> 
>> I've posted it at http://bazaar-
>> vcs.org/CasePreservingWorkingTreeUseCases
>> with links back and forward from Alex's page on CIFs.  I haven't noted
>> the potential objections raised by John or Alex and will not have time
>> before I leave
> 
> But I see no comments either here or on the Wiki.
> 
> Any advice on what more needs to be done to get this ball rolling?
>  
> Thanks,
> 
> Mark

So my feeling would be to add functions to expose the true name on disk.
Note that the way python does it actually won't work for us. In
'case_ok' it does the check: "we have a stat return for 'foo.py', now
let's make sure it is exactly 'foo.py'". But it doesn't tell you on all
platforms whether it is "Foo.py" or "fOo.py", etc.

It also, unfortunately, has to do an iteration over the contents of the
directory on some platforms. It also does a redundant "FindFiles" on
Windows, considering it uses 'FindFiles' to do the stat() call.

So for something like "add" I would like a WorkingTree api for
canonicalizing the path that we are given. 'smart_add' has a nice
location for doing this when we:
# validate user file paths and convert all paths to tree ...

As for the rest of the time...

'iter_changes' would need a way to track which files 'missed' on the
first pass, and then come back and correct it. We have a slight
advantage that we generally work in a directory-at-a-time, though there
are still problems. I believe the output order is defined as
sorted-per-directory, so you can't yield anything once you have a miss,
until you get to the end and resolve whether it was a *real* miss or not.

'bzr commit' should be switched over to using an 'iter_changes' style
operator. It can't be exactly 'iter_changes' because of the need to
resolve file ancestries, etc, but it would be very similar (and
identical in the no-merge case.) It might be reasonable to start with
that kind of function and make it capable of handling case issues the
way you would like to.

We'll probably also need a way to do something like
"case_insensitive_path_to_id()". So that doing:

touch foo
bzr add foo
mv foo Foo
bzr add Foo

doesn't try to add Foo twice even though it has a different name now.

I'd also like to see this stuff factored/parameterized enough that it
has near 0 overhead on platforms that don't need it.

Thoughts?

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkj/gx4ACgkQJdeBCYSNAAMfFACfT+EA4sQQ+/KmlrVMPtmOA5rK
0F0AnR7da579W5XzGbxJVlRdY33JRc0+
=Ift0
-----END PGP SIGNATURE-----