Comment 10 for bug 715000

On 9 February 2011 10:00, Robert Collins <email address hidden> wrote:
> On Wed, Feb 9, 2011 at 11:23 AM, Martin Pool <email address hidden> wrote:
>> On 9 February 2011 08:32, John A Meinel <email address hidden> wrote:
>>> I'm also pretty sure that at least James didn't realize that
>>> RepoA._fallback_repositories != [RemoteRepoB, RemoteRepoC]
>>
>> I did not realize that either.  I think it's kind of a dangerous
>> interface that way.
>
> Its the immediate fallbacks; they can have their own - and a repo can
> have N immediate fallbacks because of shared repositories with stacked
> branches in the repo.

Sure. I would just change it to be called _immediate_fallbacks or
something so that people don't misinterpret it.

> Flattening it is possible, but you want to make sure you still have
> the fallback repositories know their own fallbacks so they can
> maintain their own invariants about inventories, revisions etc. The
> downside if you flatten it then is that you need two apis - a
> non-recursive one and a recursive one, or you'll end up handling
> fallbacks twice - once in the top level, and then once in the first
> level. Of course this can still happen when you have several direct
> fallbacks, but thats very uncommon today.

It seems like either recursing or flattening them can get into
inefficiency. At the moment flattening it from a method call at the
moment we want to know the list seems easiest.

If you get the chance to review
<https://code.launchpad.net/~mbp/bzr/715000-stacking/+merge/48886> I'd
appreciate it.
If you have a chance I'd like to see your review of the patch.