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

Aaron Bentley wrote:
> John A Meinel wrote:
>> Aaron Bentley wrote: 
>>> Why do we need the parent inventories?
>> Stacking requirements. The specific issues are:
> 
>> 1) When accessing a stacked branch via bzr+ssh the *server process* does
>> not have access to the backing repository.
> 
> It would be nice to support server-side bundle application, but it is
> not a requirement.  Bundles are deltas, and the client usually needs to
> read from the repository in order to install them.  If that requires
> that fallbacks be available, I think that's a reasonable extension of
> the current behaviour.
> 
>> 1) If you insert an line-delta for the XML inventory into the stacked
>> branch, then it only references newly introduced texts, and does not
>> reference all possible texts.
> 
> All possible in what context?  We certainly don't want to reference
> every text in the repository.
> 
>> Thus even though we don't have the parent
>> inventory later when doing "streaming fetch" we don't try to send more
>> data then we have available because it just wasn't referenced.
> 
> If you are suggesting that installing an inventory requires installing
> all the texts it references, that would require doing it on the client
> side, because storing all that in the bundle is pointless waste.

Assume you have revisions a, b, c

In the base repository you have a & b
in the stacked you have c

All revisions have texts foo, bar, baz
'c' only modifies baz

At that point, we need to be able to create a fulltext for the inventory
at c. Either via
1) A fulltext of c
or
2) A fulltext of a parent, and a delta chain including c.

At that point, the stacked branch has 2 options:

1) If it doesn't have inventory for b, it must have the file content for
foo, bar and baz
2) If it does have inventory b, it only needs the file content for baz.

The basic requirement is that a stacked repository should be independent
of its fallback for the case of streaming fetch. So either we

1) Insert a parent inventory so that we can determine that someone who
has revision 'b' will already have these file keys
or
2) Have the file keys ourselves so that we can ensure someone fetching
'c' has everything they need.

Does that make sense?

> 
>> 2) However, if you are at the end of a delta chain, etc, and you insert
>> a "fulltext" for the XML inventory, suddenly when doing streaming fetch
>> from that stacked branch, it will see all these text keys that it thinks
>> it needs to transmit, for which it cannot find in the local repository.
>> [and boom].
> 
> I think it doesn't make a lot of sense for a stacked repository to have
> a copy of every text referenced in any of its inventories, so I don't
> really get this.

Which is why we want to insert the inventories for parent revisions, so
that *without hitting the fallback* we can determine what file keys do
not need to be fetched.

John
=:->

> 
>> My point was that the streaming code might not look at the
>> Branch.last_revision() and instead look at "is revision in
>> Repository.all_revision_ids". And if you have a local shared repository,
>> it *will* have the revisions you are trying to bundle.
> 
> Okay, I will make sure that the new bundle format uses
> Branch.last_revision to determine what to send.
> 
> Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkpfo9MACgkQJdeBCYSNAAMhgQCeODMwlt6M0GyV9LW3m2vtSYPx
atIAoKzsDkDHSP1XHFol6CuIkz5YxK2X
=7YQB
-----END PGP SIGNATURE-----