Code review comment for lp:~maxb/bzr/deref-in-set-stacking

Revision history for this message
John A Meinel (jameinel) wrote :

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

On 5/20/2011 12:06 PM, Max Bowsher wrote:
> Max Bowsher has proposed merging lp:~maxb/bzr/deref-in-set-stacking into lp:bzr/2.3 with lp:~maxb/bzr/normalize-lp as a prerequisite.
>
> Requested reviews:
> bzr-core (bzr-core)
>
> For more details, see:
> https://code.launchpad.net/~maxb/bzr/deref-in-set-stacking/+merge/61730
>
> This branch adds directory service dereferencing of the URLs passed to --stacked-on=...
>
> One aim of this was in the hope of making --stacked-on=lp... work. It doesn't yet - ironically it would work if we still resolved lp: via XMLRPC - but now that we use the /+branch/... syntax to trigger server side lookup, we run into the problem that Launchpad does not *currently* allow /+branch/ for stacking locations. I hope to fix this in Launchpad.
>
> Another benefit is that if users have custom plugins implementing shortcut URLs, this will ensure that we do not leak these custom shortcuts into the branch stacking location, potentially breaking things for users without the same set of custom plugins.

I don't think this is appropriate for 2.3. Or at least, we should land
it in 2.4 first, and then make sure there isn't extra fallout.

What if, instead of using directory_service.directories, we just used

normalized_url = get_transport(stacked_on_url).base

transport was also meant as a URL service, so maybe that would work for
what we need here.

Also, XMLRPC now returns +branch/foo style URLs as well. So it still
wouldn't work.

AFAIK there isn't a way to expand a lp:foo to ~user/bar/baz anymore... :(

Maybe via code.launchpad.net

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

iEYEARECAAYFAk3WSQQACgkQJdeBCYSNAAPEZACgvqt6yuOi8kqQhpEmNwVD76Ys
/dQAoMe0/4pRDOHI6xOn6Sh6+P6YYL5T
=XBoM
-----END PGP SIGNATURE-----

« Back to merge proposal