[MERGE] Add BzrDir.get_branch_stacked_on_url
Robert Collins
robertc at robertcollins.net
Wed Sep 3 04:19:13 BST 2008
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.
> 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
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080903/b0a3e782/attachment-0001.pgp
More information about the bazaar
mailing list