stacking on a remote branch is slow; perhaps should warn

I think there is definitely a chance to avoid people getting in to trouble here.

Before we get in to possible solutions let's be clear on what we want to allow, encourage, or avoid.

 * Being able to make stacked branches from the command line is useful, at least for developers and for testing
 * Having hidden (but working) options seems likely to confuse people who do have a reason to look for it (a warning might be better, as long as it's easy to recover)
 * Stacking on a remote repository is going to be slow

Some possible solutions:
 * Give a warning when --stacked is used
 * Check there is user documentation of stacking including the drawbacks
 * Show a message when opening a stacked-on branch
 * Create this by init, reconfigure, pull, so the option can be removed from branch
 * Warn (or refuse unless forced) to stack on a branch that's not on the same host as the destination (*)

Is --stacked really safer with --no-tree?

Hmm, I thought I already replied to your email but I don't see it in
Launchpad so trying again. Apologies if you get this twice.

On Mon, 2011-08-01 at 00:41 +0000, Martin Pool wrote:
> I think there is definitely a chance to avoid people getting in to
> trouble here.
>
> Before we get in to possible solutions let's be clear on what we want to
> allow, encourage, or avoid.
>
> * Being able to make stacked branches from the command line is useful, at least for developers and for testing
> * Having hidden (but working) options seems likely to confuse people who do have a reason to look for it (a warning might be better, as long as it's easy to recover)
> * Stacking on a remote repository is going to be slow
>
> Some possible solutions:
> * Give a warning when --stacked is used
> * Check there is user documentation of stacking including the drawbacks
> * Show a message when opening a stacked-on branch
> * Create this by init, reconfigure, pull, so the option can be removed from branch
> * Warn (or refuse unless forced) to stack on a branch that's not on the same host as the destination (*)

> Is --stacked really safer with --no-tree?
A lot of the working tree operations require the tree contents, which
are fetched from the stacked-on repository for every tree operation.
This also happens using the VFS, so it's annoyingly slow.

It should be a lot better once stacked branches will start saving the
data they had to fetch anyway.

With --no-tree, there aren't a lot of operations that will actually
fetch the entire tree *and* then discard the contents. There are still
some, though, so I'm not sure how useful it is to distinguish between
--tree and --no-tree in this regard.

Cheers,

Jelmer

I'm marking this Wont Fix because I don't think hiding the option would have any affect. Note that from the beginning "apparently recommended to him by somebody". Hiding the flag has no effect on someone telling you to use it. I don't think hiding the flag would help this case.
Not supporting the flag would be an option, but I don't think it is reasonable, given the genuine use case for some people.

As an aside, I did look into turning stacked branches into a cache, and it is really non-trivial. Because then things that are logically read-only start to write. And our transactional repository means you have to define what the transaction boundary is. (start_write_group/commit_write_group, etc.) 'bzr status' doesn't give any hints as to when it will start/stop trying to read more data.

Also note, that even as a cache, we need to watch out for invariants that say if a revision is present, then you have access to its inventory and the texts introduced in that rev. Otherwise you could do 'bzr log -r 1..-1' in a stacked branch, and it would fetch all the revision messages, and if it wanted to insert that into the local repository, it would then need to fetch *all* of the inventories and texts. I'm guessing someone who does 'bzr log' in a stacked branch doesn't intend to fetch the whole repository history.

John, I agree with you that just hiding it would not have help someone who was specifically recommended to use it. There is possibly a ui bug here that people could be confused about using it.