[MERGE] Fix fetch from stacked repositories (#248506)

[Aaron Bentley]

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

John Arbash Meinel wrote:
> Aaron Bentley wrote:

> 1) fetching in Pack repositories is generally performed by creating a
> Packer, and listing the revisions you want in the target pack.

Well, you can also not list the revisions you want, and then it just
copies everything.

> 2) Now that stacking branches has moved up a layer, there are no more
> fallback pack files the Repository object attached to a stacked Branch
> object. So the Packer only sees the limited history in the "stacked"
> repository.

Right.

> 3) This changes the fetch logic to go back to
> "target.insert_data_stream(source.get_data_stream....())" because the
> Repository level knows to fall back to the stacked-on repositories.

Well, target and source here are VersionedFiles, and they also know
about falling back.

> I might prefer it if the test_fetch_copies_from_stacked_on actually had
> a single commit in the stacked_dir, and then fetched rev2 and asserted
> that it got both rev1 and rev2.

I think that doing more than the minimum in tests just muddies the
waters, and makes it harder to understand what you're actually testing.

But I'll add an additional test with "rev2".

> Mostly because it feels a bit like there would be alternative
> implementations that would pass this test, but not be correct overall.
> Like one that said the interesting revision isn't here, so I'll find it
> elsewhere, but not actually look at the *ancestry* of the interesting
> revision.

I would hope that a bug like that would cause all kinds of failures in
our existing tests.

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

iD8DBQFIfmSZ0F+nu1YWqI0RAojXAJ9Bf7+4rfuODM+o7DkyGWTGEWeexwCdGJBd
73f8l2h/mWlRxOYoyNM9fdE=
=ZQSW
-----END PGP SIGNATURE-----