[MERGE] Add BzrDir.get_branch_stacked_on_url

[John Arbash Meinel]

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

Aaron Bentley wrote:
> Robert Collins wrote:
>> By the same token, we don't strictly need a Repository object to be open
>> either when we open a tree or branch, but we settled a while ago, I
>> thought, that it was safer and better to do so. I think the same
>> arguments apply here.
> 
> I'm pretty sure I don't agree.  Could you repeat the arguments?
> 
> To me, there is a significant difference, because a stacked branch that
> can't access its stacked-on branch can still support many, many
> operations.  Lack of a Repository, on the other hand, is crippling.

Well, I would generally fall onto the "don't open if you aren't going to use
it". I think, Robert, that you settled your feelings on this, and the rest of
us didn't care quite enough to push the argument.

For example, I'm quite unhappy that doing:

$ bzr co --lightweight lp:upstream
$ cd upstream
$ bzr status

Has to connect to Launchpad even though we request 0 data. It changes the time
for "bzr status" in a clean tree from sub-second to 3-5 seconds (depending on
the ssh handshake.)

It also means you can't do "bzr status" in a lightweight checkout when the
network is down. For no reason other than "when you can't access the
branch/repository we want to tell the user."

I do respect your opinion that we don't want things to be secretly broken for
a long time before the user does something to trigger it. I would like to find
a good balance between the two.

> 
>> A stacked branch where the stacked on Repository
>> is no longer accessible should be raised as a problem as soon as
>> possible to the user.
> 
> I'd rather optimize for success than failure.  I think we should open
> stacked branches as quickly as normal branches, which means not hitting
> the network to open stacked-on branches, since they may not be needed.
> 
> I think if an operation can complete locally without using external
> resources, then it should do so.
> 
> That's how shallow branches will work.  Or are you saying that shallow
> branches are a bad idea?
> 
> Aaron

I agree with Aaron here, that if we don't need expensive resources, we
shouldn't allocate them. (Such as connecting to a remote ssh machine.)

Note that ssh connection timings vary wildly. On my local network:

$ time ssh localnet true
0.680
0.255
0.244

Not too bad.
$ time ssh devpad true
4.796
3.012
2.972

$ time echo hello | ssh bazaar.launchpad.net bzr serve --inet --directory=/ \
    --allow-writes
2.859
2.880
2.969

$ time bzr status (bzr.dev)
0.285

So basically, by requiring to open the remote connection, it changes something
that would be 0.28s into something that is 2.8s+0.28s (about a full order of
magnitude slower.)
Further, it impossible to do when the network is down, even though the network
connection is not used.

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

iD8DBQFIvVQlJdeBCYSNAAMRAqBTAJ42GtK3ypuvqCDSJU25Gw0VjRx7YwCfShl9
7UUKRpbLmmPqQGtd0cn48RE=
=fuz4
-----END PGP SIGNATURE-----