OS X tests status update

[Vincent Ladeuil]

>>>>> "Guillermo" == Guillermo Gonzalez <guillo.gonzo at gmail.com> writes:

    >> And *I* am using a case-sensitive HFS+ and they fail too. I
    >> suspect the 'preserving-case' HFS property (even if it shouldn't
    >> show up for me, weird).

    Guillermo> indeed..
    Guillermo> after a little google search[1], I learned that by default HFS+ is
    Guillermo> case-preserving AND case-insensitive.

case-preserving implies case-insensitive

The only difference is that case-preserving retains the file name
used at creation time. After that point, the file can be accessed
with any case but will always appear with its original name
(except when it doesn't :-/ ).

vila:~/tmp :) $ mkdir osx
vila:~/tmp :) $ cd osx
vila:~/tmp/osx :) $ touch Toto
vila:~/tmp/osx :) $ ls 
Toto
vila:~/tmp/osx :) $ ls toto
toto
vila:~/tmp/osx :) $ 

    Guillermo> So, I wondering if we should to teach bazaar this
    Guillermo> special OS X/HFS+ behaviour or we can reuse some
    Guillermo> of the win32 fs magic?

Reusing the win32 fs magic was the intent of
CaseInsensitiveFilesystemFeature.

Since the tests are currently failing, I think we should try
harder.

Given that only a few devs fully understand the difference
between case-preserving and case-insensitive (and even fewer
*care*), I don't think anybody will *require* bzr to handle
them. So treating HFS+ as case-insensitive sounds reasonable.

    >> 
    >> Can you publish your branch on launchpad in the ~bzr namespace so
    >> that we can both commit on it ?
    >> 

    Guillermo> done: lp:~bzr/bzr/osx_tests_fix

Thanks, I've pushed an update to your first patch to:

- consistently use osutils.mkdtemp instead of tempfile.mkdtemp
  (but I wonder if it's really the right approach since *one*
  test
  (bzrlib.tests.branch_implementations.test_permissions.TestPermissions.test_new_branch)
  really want to set the group sticky bit... Is it really worth
  it to add a chown call for every temp directory (as you do in
  _mac_mkdtemp) ?

- fix a bug in workingtree fixing 3 more tests

Down to 4 failures, 9 errors :-)

  Vincent