[MERGE] Add BzrDir.get_branch_stacked_on_url

[John Arbash Meinel]

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

Robert Collins wrote:
> On Tue, 2008-09-02 at 09:56 -0500, John Arbash Meinel wrote:
>> -----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.
> 
> Well, thats a shame.
> 
>> 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.)
> 
> status though does ask for the pending merge history graph and revision
> contents to show the user. Talking to the basis server on http for read
> only operations would be faster I suspect.
> 

Only if you have a pending merge, and only if you didn't supply
- --no-pending-merges.

>> 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.
> 
> If we can get really solid ghost support - ghosts on mainlines, ghosts
> in merge histories, then I'd like to see stacked branches behave
> somewhat more lazily, and perhaps they could replace the implementation
> of lightweight checkouts at that point.
> 
> Its harder for programmers though to have tree.branch be something that
> can blow up wherever its used - and its used a lot.
> 
> -Rob
> 

Well, for lightweight checkouts, I always felt it could be a proxy. It exists,
and on first access it connects. Rather than connecting on "Branch.open()". I
suppose format specific code might complain. But that depends more on how well
BranchReference would do its proxying.

John
=:->

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

iD8DBQFIvg9DJdeBCYSNAAMRAgFbAJ0Rqebh8yhYOOE+rRAy/hQvFwydlwCgy8rQ
k9jrlzAlewUKNh1p1vMFb1A=
=NUQ4
-----END PGP SIGNATURE-----