[MERGE][#230550] Fix spurious "No repository present" errors when accessing branches in shared repos via bzr+http.

[John Arbash Meinel]

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

Andrew Bennetts wrote:
| John Arbash Meinel wrote:
| [...]
|> A lot of these seem like incompatible API changes. Are they all on private
|> classes? I'm looking at stuff like:
|>
|> ~ class SmartTCPClientMedium(SmartClientStreamMedium):
|> ~     """A client medium using TCP."""
|>
|> - -    def __init__(self, host, port):
|> +    def __init__(self, host, port, base):
|>
|> ^- Which now has an extra required parameter. I realize this isn't really a
|> candidate for subclassing like Repository is. But AFAICT it *is* an API break,
|> and should thus be documented in NEWS.
|
| Good point.  Documented.
|
|> SmartClient.remote_path_from_transport
|>
|> sort of makes me want to cry. Why does it have to know so much about the URLs it
|> supports. Why does it treat "bzr://" so different from "bzr+http://"? It just
|> feels dirty, with the knowledge in the wrong location. I won't say it isn't
|> necessary, and certainly the function already exists and is being used.
|
| Yeah, I don't like it much either.  But to calculate a remote path given a full
| URL (i.e. a transport) you need to use the base path of the smart medium.  Now
| that 'base' is on SmartClientMedium directly, perhaps this can be pushed down
| to the individual SmartClientMedium subclasses.  Hmm...
|
| Ok, I've done that.  It wasn't too painful given that I'd already moved 'base',
| and now the special logic for bzr+http:// is confined to HttpTransportBase.
|

Thanks, that actually cleaned it up a lot IMO.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgyMgwACgkQJdeBCYSNAAP5FACgrQVwkiso+W+JeaWvAIc1PT2B
VCsAoIkzrgF6AtSRTppVooYihQvvfszT
=CxBe
-----END PGP SIGNATURE-----