[Merge] lp:~mbp/bzr/715000-stacking into lp:bzr

[John Arbash Meinel]

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


...

> One bit that looks problematic is _get_remaining_record_stream which
> seems to assume it can find the source identified by
> _get_parent_map_with_sources within it's own immediate fallbacks, and
> it doesn't seem like that's guaranteed to be true.  However, I can't
> reproduce an error with a bit of experimentation, and I don't see any
> bug reports about the IndexError I would expect this to cause:
> 
>                     vf = self._fallback_vfs[parent_maps.index(source) - 1]
> 
> Aside from that I agree, they're all ok.
> 
> Martin
> 

It isn't buggy because the source lookup is only 1 level deep. What
happens is that the lookup goes via the public api, and that hides the
actual fallback check.

So if RepoA stacked on RepoB stacked on RepoC. Then if you call
RepoA.get_stream(rev_c), then RepoA askes its fallback (RepoB), which
then proxies the data from RepoC.

So from RepoA's point of view, RepoB *has* rev_c, because it has access
to it, and can return it on request.


And I believe, this even works when RepoB and RepoC are
"RemoteRepository". This is because on the client side, the
RemoteRepository does have a fallback, even though it doesn't have a
fallback on the server side.

Which means that the *client* hides the fallback request from itself,
rather than the *server* side pulling data out of the fallback and
returning it.

Because we indirect through the public api, a server-side object *could*
return the data. But we also chose to not have the server-side object
actually have access to its fallbacks.


> owever, I can't
> reproduce an error with a bit of experimentation, and I don't see any
> bug reports about the IndexError I would expect this to cause:
> 
>                     vf = self._fallback_vfs[parent_maps.index(source) - 1]

The '-1' aspect here, is because the first entry in parent_maps is self.

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

iEYEARECAAYFAk1SsNMACgkQJdeBCYSNAANsSQCfWQInOboLLYmQ5MG0VF43R6Sp
EFQAnREMpobWOXPaGHsmrrU6UONZzgzx
=QoFd
-----END PGP SIGNATURE-----