[MERGE] Fix fetch from stacked repositories (#248506)
John Arbash Meinel
john at arbash-meinel.com
Wed Jul 16 21:45:26 BST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Aaron Bentley wrote:
| Hi all,
|
| This patch fixes bug #248506, which would prevent required revision data
| from being fetched from stacked repositories. Now that stacking is no
| longer pack-based, we must use higher-level operations, e.g.
| VF.insert_record_stream, that do use stacking.
|
| Robert expects that performance will be similar to pack-based
| performance, but since this is a potential data-loss scenario, it would
| be worth fixing even if it was a slowdown.
|
| Aaron
Let me make sure I understand the issue correctly.
1) fetching in Pack repositories is generally performed by creating a
Packer, and listing the revisions you want in the target pack.
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.
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.
BB:approve
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.
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.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkh+XeYACgkQJdeBCYSNAAOSggCfSipNXIoALN/6By+DLzwIOrCl
qu4AniHibO4k8o0Vr8wG9W3Cn6awO2tO
=QJG2
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list