Aaron Bentley wrote:
> Robert Collins wrote:
>> The critical component was truely critical and has been cherrypicked
>> into lp production some time ago. The lp task would be appropriately
>> closed, I think.
>
> This is hitting us any time we use bundles to create/update branches.
> It's a pretty high-frequency, high-irritation event.
>
> Aaron
so... is this happening when:
1) applying a bundle to an existing stacked branch?
2) applying a bundle that was created *from* a stacked branch?
If I was guessing, I could easily say that the bundle code:
1) Doesn't contain the fulltext for inventories of parent revisions,
nor does it contain the data for all texts that are referenced by the
inventories that it *does* have.
2) Thus when creating a stacked branch from the bundle, we don't have
the parent inventories to *insert* into the new stacked repository.
(Without going to the backing repository and pulling them out)
3) And thus the stacked branch is now broken.
This points the failure at the "insert data from a bundle" code, causing
it to generate invalid stacked repositories.
This would all be simplified quite a bit if we just made a bundle
effectively just a way to transfer the data for the stream that you get
out of StreamSource. There is a small caveat that the bundle *also*
needs to think of itself as not containing any data, and thus does the
same "what is missing" checks that a stacked repository does.
So put another way:
1) BundleRepository just sets itself up as a stacked repository, stacked
on top of a hypothetical repository that only has the minimal data
defined by the target revision.
2) Alternatively we could go to the real target branch and use that.
However at present we have a habit of setting submit_location to a local
mirror, and obviously that will generate the wrong information about
"what data do you have that I don't".
I'll see if I can trivially recreate this.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Aaron Bentley wrote:
> Robert Collins wrote:
>> The critical component was truely critical and has been cherrypicked
>> into lp production some time ago. The lp task would be appropriately
>> closed, I think.
>
> This is hitting us any time we use bundles to create/update branches.
> It's a pretty high-frequency, high-irritation event.
>
> Aaron
so... is this happening when:
1) applying a bundle to an existing stacked branch?
2) applying a bundle that was created *from* a stacked branch?
If I was guessing, I could easily say that the bundle code:
1) Doesn't contain the fulltext for inventories of parent revisions,
nor does it contain the data for all texts that are referenced by the
inventories that it *does* have.
2) Thus when creating a stacked branch from the bundle, we don't have
the parent inventories to *insert* into the new stacked repository.
(Without going to the backing repository and pulling them out)
3) And thus the stacked branch is now broken.
This points the failure at the "insert data from a bundle" code, causing
it to generate invalid stacked repositories.
This would all be simplified quite a bit if we just made a bundle
effectively just a way to transfer the data for the stream that you get
out of StreamSource. There is a small caveat that the bundle *also*
needs to think of itself as not containing any data, and thus does the
same "what is missing" checks that a stacked repository does.
So put another way:
1) BundleRepository just sets itself up as a stacked repository, stacked
on top of a hypothetical repository that only has the minimal data
defined by the target revision.
2) Alternatively we could go to the real target branch and use that.
However at present we have a habit of setting submit_location to a local
mirror, and obviously that will generate the wrong information about
"what data do you have that I don't".
I'll see if I can trivially recreate this.
John enigmail. mozdev. org
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkp eQA4ACgkQJdeBCY SNAANpAwCfajcwh 5TE87OZ9yHFrjm2 UmNk 7i8bVrbDMMvCibP UdbsSq
R14AnjjmiO/
=gcg6
-----END PGP SIGNATURE-----