Comment 40 for bug 390563

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

John A Meinel wrote:
> Aaron Bentley wrote:
>> 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?

After applying the bundle to the stacked branch, our branch puller is
unable to pull the branch.

> 2) applying a bundle that was created *from* a stacked branch?

That's not the case I was describing. I don't think anyone's creating
bundles from stacked branches.

> If I was guessing, I could easily say that the bundle code:
>
> 1) Doesn't contain the fulltext for inventories of parent revisions,

Bundles aren't meant to contain fulltexts of any inventories.

> nor does it contain the data for all texts that are referenced by the
> inventories that it *does* have.

It contains the data for the texts that are referenced by the
inventories it does have, as long as the referenced texts are new. If
they are present in the basis revision, they will not be included.

> 2) Thus when creating a stacked branch from the bundle, we don't have
> the parent inventories to *insert* into the new stacked repository.

Why do we need the parent inventories?

> (Without going to the backing repository and pulling them out)

add_mpdiffs reconstructs the fulltexts and calls
VersionedFile.add_lines, so yes, it would hit the backing repository to
regenerate the fulltexts. But it usually wouldn't try to insert
inventories that were already present in the backing repository.

> 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.

I started work on that at the sprint.

> There is a small caveat that the bundle *also*
> needs to think of itself as not containing any data

Pardon?

>, 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.

In the Launchpad case, we are stacked on the real target branch.

> 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".

If the head revision of the local mirror is accurate or stale, it may
bundle more data than is strictly needed, but not too little.

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

iEYEARECAAYFAkpeRlYACgkQ0F+nu1YWqI3OnQCdEitj+5LO9P19+wBuPj7VcQkw
OhIAn02lm1hJDHvewisLgPTjkDlo/jlc
=Xf9G
-----END PGP SIGNATURE-----