[RFC][MERGE] case sensitivity on Windows
John Arbash Meinel
john at arbash-meinel.com
Tue Dec 2 14:26:49 GMT 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark Hammond wrote:
> [Resending as bundle-buggy missed it before...]
You have to start with [MERGE][RFC] or [MERGE/RFC], starting with [RFC]
prevents bundle buggy from finding it.
>
> -------- 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.
We already detect whether the filesystem that the WT is on is
case-insensitive. As part of WT.__init__ we call:
def _detect_case_handling(self):
wt_trans = self.bzrdir.get_workingtree_transport(None)
try:
wt_trans.stat("FoRMaT")
except errors.NoSuchFile:
self.case_sensitive = True
else:
self.case_sensitive = False
self._setup_directory_is_tree_reference()
So you can just check:
if self.case_sensitive:
...
else:
... #use canonical_path()
John
=:->
>
> * 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
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkk1RakACgkQJdeBCYSNAAONNQCgnVvupU+e0I48Vybnt/9I+Gv/
LjwAoNlLwqDnhlDKvld+/dC1hfo2tLFO
=iT5y
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list