[RFC/MERGE] case sensitivity on Windows

[Mark Hammond]

[Martin writes]

> I don't think you should write against the internals of the dirstate.
> Instead, walk down through the inventory, just like you do in the
> filesystem.  For each directory, look through its .children list
> case-insensitively, to find the actual name of the next component of
> the path.

Doh!  Yeah - that is a lot easier :)

I've attached a new patch which implements this and addresses your other
comments from the earlier review.  Although this doesn't complete the
support for case-insensitive file-systems, it is a good step towards that
and should cause no regressions.  However, I expect there to be a few main
areas of concern:

* The names of the functions:

- osutils.canonical_relpath() - like osutils.relpath(), and named "in its
spirit" 
- WorkingTree.canonical_relpath() - like WorkingTree.relpath(), also named
in its spirit
- Tree.get_canonical_path() to perform the case-insensitive search of the
  inventory.  Named 'in the spirit' of existing methods
Tree.get_symlink_target(),
  Tree.get_file_by_path(), Tree.get_file(), etc

The end result is 2 sets of functions that perform similar functions, but in
different ways - but that problem seems to already exist - Tree.get_file(),
Tree.get_symlink_target() all work on the inventory, but their name gives no
indication it isn't actually looking at a WorkingTree on disk.  I welcome
better names.

* The performance of Tree.get_canonical_path() when an 'invalid' name is
specified.  If the input arg is the name of an existing item, I expect the
performance will be OK as the name is looked up as specified.  However, if
the name specifies an inventory item that does *not* exist, we will walk the
inventory as deeply as we can find matches.  OTOH, it would seem rare that
non-existing items are passed on the cmdline.  We may want to restrict use
of this function to Windows, but as noted in previous comments, this
functionality isn't actually restricted to Windows (think FAT32 devices on
Linux), so advice on how to best approach this is needed.  My testing on
Linux shows no regressions caused by this patch as it stands.

* There is a new "expected failure" relating to a remaining limitation in
'bzr add'; as noted in the exception message, I believe that to resolve this
it might be necessary to move the case_sensitive attribute up the chain from
WorkingTree into MutableTree, or otherwise push the required functionality
down into WorkingTree.


Thanks,

Mark

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cicp_filesystem.patch
Type: application/octet-stream
Size: 44279 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081118/dd2b5ac1/attachment-0001.obj