[MERGE/RFC] case sensitivity on Windows

[Mark Hammond]

[one more go - apparently the HACKING doc isn't quite accurate - the 
subject must *start* with "[MERGE"...oh well]

-------- Original Message --------
Subject: RE: [RFC/MERGE] case sensitivity on Windows
Date: Tue, 18 Nov 2008 10:49:19 +1100
From: Mark Hammond <mhammond at skippinet.com.au>
To: 'Martin Pool' <mbp at canonical.com>
CC: 'Bazaar' <bazaar at lists.canonical.com>

[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: 44280 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081202/4eda79f8/attachment-0001.obj