journalled inventories

Robert Collins robertc at robertcollins.net
Fri Oct 26 17:34:49 BST 2007


On Fri, 2007-10-26 at 08:19 +1000, Martin Pool wrote:
> 
> We should consider two ways other than commit when inventories get
> generated: converting from other vcs's, and converting from prior bzr
> formats.  Making the hash of the newly-generated validator depend on
> the representation of previous inventories has two risks there.


>   One
> is that converters can't just say "this is the representation of
> foreign inventory X" without replaying (part of) history up to that
> point. 

One way they can convert is to always emit a length-0 journalled delta.
If we permit the individual inventory lines records to be compressed by
the storage layer, then this would work well. E.g.:

Native journalled inventory commits::
 - generate a journal entry
 - add a 'knit' record to the inventory knit containing the journal, and
request it be stored undelta'd (because we know it doesn't need it).

Converters from e.g. our current inventory system:
 - generate a new journal against EMPTY
 - add a 'knit' record to the inventory knit containing the journal, and
request it be stored as a text delta against the inventory of the
commits left most parent. (Which results in nearly exactly the same
behaviour as today).

>  Secondly, it would be unfortunately if the heuristic caused
> two upgrades of identical inventories to get different representations
> or validators.  The representation and validator should be the same
> IFF the input inventory is the same (modulo hash collisions.)

If converters do not emit anything other than journals against EMPTY,
then they will get the same representation and thus validator for the
same inventory. I think its ok for a converter to do this, as it does
make it easier to say 'your revision X has not been attacked vs my
revision X', with a tradeoff of not improving performance for existing
inventories.

A related note though: as journalled inventories don't change the model
of 'inventory', its possible to losslessly export them to regular
inventories; so a converter might be asked to convert a revision that
originated in a native journalled environment from a non-journalled
representation into a journalled representation, and in this case it
will almost certainly get a different validation and validator if we use
the converter logic I described above. This is non-optimal, but, I think
it is preferrable to design in support for that case rather than
preventing people pushing data from a journalled environment to a
non-journalled one.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20071027/f1b7bfa7/attachment.pgp 


More information about the bazaar mailing list