[REGRESSION] bzr 1.17 does not use _knit_load_data compiled extension

Martin Pool mbp at sourcefrog.net
Wed Jul 29 05:37:39 BST 2009

2009/7/28 John Arbash Meinel <john at arbash-meinel.com>:
> Hash: SHA1
> Andrew Bennetts wrote:
>> Andrew Bennetts wrote:
>> [...]
>>>> _knit_load_data_c was renamed to _knit_load_data_pyx by Vincent in bzr.dev
>>>> revno 4472 but Vincent did not update all imports. At least not in 1.17.

I think this really shows a hole in our test coverage - to me the hole
is more worrying than this particular failure, which as John says only
affects quite old formats.  I filed
https://bugs.edge.launchpad.net/bzr/+bug/406113 to track it.

There have been several cases where people have not been using the
extensions or not been using the correct extensions and it causes
confusing behaviour, or it causes them to see bzr as being slower than
it can be.

I think the general policy of silently falling back to the Python
implementations at run time if we can't load the extensions is wrong.
I realize there are cases where people really do want to just use the
Python versions without being nagged, but I think they are very
exceptional cases.  Normally it will indicate a problem either in the
bzr source or in the packaging or build process or in the user's
installation.  In any of those cases we should raise a red flag.
Ideally we would trap this before the user runs bzr but if not, we
should still warn.

Therefore I want to merge something like the following diff, from the
branch attached to that bug.  It lets you turn it off, but by default
it will warn.

I'd rather have some users tell us when we get it wrong than have it
remain broken.

>>>> I don't know is it critical for performance (I suppose -- yes), but it does
>>>> not sound right for me anyway.
>>> Ouch, yes.  That does seem to be case.  I think that's a critical bug worth
>>> making a 1.17.1 release for.  Thanks for catching that!
>> I've landed a fix in bzr.dev r4574.  If someone does go ahead with making a
>> 1.17.1 (Martin maybe?  I think jml is unavailable for RM duties this week) then
>> they should cherrypick that.

Please merge it yourself to 1.17.

> So it isn't as critical as one might think. I'm fine doing a 1.17.1 for
> it, but it only effects people using "knit" format repositories, which
> have been deprecated for quite some time.

Martin <http://launchpad.net/~mbp/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tmp.diff
Type: text/x-patch
Size: 8249 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090729/76472088/attachment.bin 

More information about the bazaar mailing list