[RFC] deprecate mutable inventories

[John Arbash Meinel]

Aaron Bentley wrote:
> Robert Collins wrote:

...

>>> Then mutation operations on Tree take the place of the current
>>> poke-at-inventory logic.
>>>
>>> TreeTransform will need some assistance here - the current unversion()
>>> call is part of that, but AIUI the next step is allowing the
>>> transformations that violate posix to have a limbo working area.
> 
> I don't see TT requiring that change to support an inventory-free mode
> of operation.  As long as Tree supplies a similar interface to
> Inventory, it should be easy to operate on Tree directly.
> 
> Or are you also talking about getting rid of InventoryEntries?

I think he is trying to get rid of InventoryEntries at certain levels.
In my profiling, I found creating an object for every record on disk to
actually be rather expensive (versus the cost of reading it all in as
plain strings and lists).

> 
> I don't know if there's a way for Trees to manage limbo in a way that
> would really make me happy.  I don't like magic paths, but if we don't
> use magic paths, then we have to replicate a bunch of operations for
> files that are in limbo.  And how to identify them, then?  It seems like
> it very quickly tries to subsume TreeTransform.
> 

What logic do you specifically need? It seems that all TreeTransform
does is add, remove and rename. As I recall, you need temporary file
ids, because there may be collisions.

>>> As a for instance on why this is important, consider the trivial case of
>>> unversion. unversion of in dirstate *does not remove the row*. Say we
>>> are unversioning 'foo' with id 'foo-id', which is in the basis tree.
>>> We go from:
>>> 'foo', 'foo', 'f', statdata, 'foo-id', 'f', 'rev1', 'f', '', 'foo',
>>> '123', 'n', 'abcdef012345678123791231231231234123'
>>>
>>> to:
>>> '', '', '', statdata, 'foo-id', '', 'rev1', '', 'foo', '123', 'n',
>>> 'abcdef...'
>>>
>>> The fields that change are the relpath (it is not versioned anymore, no
>>> path), name(ditto), file type (ditto).
> 
> 
>>> (See my other email for a variation on this, where we have two stages of
>>> cleanup - but still, until the file-id has no references in the set of
>>> all inventories for the tree - the parents and the current one - it will
>>> have a row in the tree).
> 
> This will be publicly exposed?  I would hope not.

Exposed in what sense? I think it will be exposed to some layer, but not
any higher. Like certainly no higher than Tree. Dirstate could be
directly translated into Inventories, but it would be inefficient. So
Robert is trying to restructure the interfaces to keep efficiency.
(Especially for stuff like .changes_from)

For example, we could use Inventories, but then on any change, we would
have to completely rewrite the entire dirstate file. After mutating
Inventory, you need to read the dirstate, compute the changes, apply
them, and write a new dirstate.

...

> 
> It's a bit scary to see how much of this data is redundant with the
> filesystem.
> 
> Aaron

Because dirstate is also the hashcache. We can just make it flexible
about if a kind changes, the dirstate is updated. You still need to stat
the filesystem, but if the packed stat matches, you don't need to do any
more work, rather than just returning the dirstate record.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060912/df77217c/attachment.pgp