Comment 39 for bug 390563

Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 390563] Re: absent factory exception from smart server when streaming 2a stacked branches

-----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
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpeQA4ACgkQJdeBCYSNAANpAwCfajcwh5TE87OZ9yHFrjm2UmNk
R14AnjjmiO/7i8bVrbDMMvCibPUdbsSq
=gcg6
-----END PGP SIGNATURE-----