[RFC] deprecate mutable inventories

[Aaron Bentley]

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

Robert Collins wrote:
> I know this has been sort-of-mentioned, but I've only just now really
> got a clear handle on the issues that have been making me feel that
> Inventory is more of a burden than a benefit.

I must admit, the distinction between an Inventory and a Tree is fairly
weak, a tree being mostly a superset of the Inventory interface.

> What would be ideal IMO is that we remove the _inventory attribute of
> all trees, and make the Tree interface satisfy our needs efficiently.

I don't get this.  You're talking about removing Tree._inventory, but
not Tree.inventory ?

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

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

> consider a subdir in dirstate: there are no parent pointers - each row
> is key data followed by the parent data for this path:
>  relpath, name, kind, stat, file_id, versionedkind, [[revision, kind,
> dirname, basename, size, executable, sha1] ...]

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

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

iD8DBQFFBq9+0F+nu1YWqI0RAvqRAJ4rEeD4MweuWy8/4qYXONQ4pFZWlQCfdJLZ
w072XpwHvEzD1TJ8D3URS+0=
=RojB
-----END PGP SIGNATURE-----