[BUG](regression) 'bzr pull' into a bound branch fails
John Arbash Meinel
john at arbash-meinel.com
Mon Oct 22 02:35:23 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Andrew Bennetts wrote:
> John Arbash Meinel wrote:
>> Basically, the schemes need to be registered where the protocol is registered.
>> Rather than in the file they are imported in. (In bzrlib/transport/__init__.py
>> rather than in bzrlib/transport/<protocol>.py)
> I agree.
> John Arbash Meinel also wrote:
>> I just wanted to comment that since this is an import-time ordering bug, I'm
>> not sure that we can write a test case for it.
>> But we certainly can go through and move all 'register_netloc' calls into
>> Though honestly, maybe we should just have it as part of the
>> 'register_transport' functionality. In fact, I think the only ones that
>> wouldn't be registered are http[s] (because it is already there) and file:///
>> (doesn't use a host, though it might still be netloc safe with a host of ''),
>> and maybe sftp.
>> We could just have a "register_lazy_transport(..., register_netloc=False)" for
>> those. (Yes, I would rather default it to True, though if that is considered an
>> API break, we could do the opposite.)
> Hmm, I think it should be on register_transport_proto, rather than
> register_lazy_transport. I'm ambivalent about the choice of default value, but
> True is probably ok.
Yeah, when I implemented it, that is where I did it. (Since you have multiple
transports sharing the same 'proto'.)
> Otherwise I agree that this is probably the best approach; it leaves no room to
> have the protocol registrations out-of-sync with the URL parsing, so this
> approach seems to me to be obviously The Right Thing.
I ended up defaulting it to False because we have at least as many decorators
as protocols that actually want it set True.
But if you follow the thread between Vincent and myself, you'll see that we
might just grab urlparse internally, so we can just set it true for all the
possible decorated variants.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar