!!! all tests from test_non_ascii failed on win32

Alexander Belchenko bialix at ukr.net
Fri Oct 12 20:10:09 BST 2007


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

John Arbash Meinel пишет:
> Alexander Belchenko wrote:
>> When I'm testing the recent patch from Lukas I found that almost
>> ALL blackbox non-ascii tests are failed with the same error KeyError:
> 
> ...
> 
>>   File "C:\work\Bazaar\mydev\bzr.dev\bzrlib\dirstate.py", line 1231, in
>> get_lines
>>     lines.extend(map(self._entry_to_line, self._iter_entries()))
>>   File "C:\work\Bazaar\mydev\bzr.dev\bzrlib\dirstate.py", line 1000, in
>> _entry_to_line
>>     entire_entry[tree_offset + 3] = DirState._to_yesno[tree_data[3]]
>> KeyError: None
> 
>> ----------------------------------------------------------------------
> 
> 
>> I'll try to run full selftest ASAP, but it seems that there is a BIG
>> regression on win32, either in bzrlib or tests.
> 
>> Alexander
> 
> It looks like something is setting "executable = None" rather than "executable
> = True" or "executable = False".
> 
> Just to check, do you get the same result if you run "bzr selftest --no-plugins
> ..." ?

I'm always run tests with --no-plugins flag.

> 
> Otherwise I don't see how it is happening. When we "Dirstate.add()" we set the
> executable field to False. And on win32 when we update_entry we use:
> 
> def _is_executable_win32(self, mode, saved_executable):
>   return saved_executable
> 
> I agree that this seems like a serious regression, I just don't quite
> understand what is causing tree_data[3] to be set to None.
> 
> 
> Ah.... maybe this one:
> 
> def _inv_entry_to_details(self, inv_entry):
> ...
>         elif kind == 'file':
>             fingerprint = inv_entry.text_sha1 or ''
>             size = inv_entry.text_size or 0
>             executable = inv_entry.executable
> 
> We could try:
> 
>   executable = inv_entry.executable or False
> 
> Does that fix the problem? I'm not sure why inv_entry.executable isn't being
> set. Maybe we removed one of the "_read_state_from_tree()" calls, or something
> else that was supposed to set it.
> 
> Can you investigate further?

I'll try.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHD8aRzYr338mxwCURAk/rAJ9M8KfrX2b7oACMJKxJPdBB0JNj/ACfbLkU
cgerkb138K4New35VtMhI2c=
=ClqP
-----END PGP SIGNATURE-----



More information about the bazaar mailing list