[RFC] Inventory.__delitem__ considered harmful

Aaron Bentley aaron.bentley at utoronto.ca
Thu Sep 7 14:03:45 BST 2006

Hash: SHA1

Martin Pool wrote:
> I suspect Robert wanted to get rid of it as a general move towards
> hiding the mutable inventory inside the working tree -- so code will say
> WorkingTree.unversion rather than del Inventory[].

I think it makes sense for TreeTransform to operate on the inventory
level, not the WorkingTree level.  In fact, the greatest efficiency
comes if TreeTransform is allowed to violate Inventory invariants while
applying transforms, because TreeTransform itself guarantees that no
transform's output will violate an inventory invariant.  (It will raise
an exception if you try to apply a transform that unversions a parent
without unversioning all children.)

It removes inventory entries for two reasons:
1. to unversion files
2. to move an entry from one parent to another without violating invariants.

WorkingTree.unversion would not satisfy the second use very well.

> I'm somewhat less keen than I once was on making objects support
> collection protocols if they're not really collections, rather than
> having Inventory.remove().

I'm not sure what behaviour you're suggesting for Inventory.remove, but
I would suggest having it raise an exception if any child of the entry
is versioned (which is what I was going to suggest for
Inventory.__delitem__).  Then we can implement
Inventory.remove_recursive on top of that, which is what TreeTransform
would use.

But I should explain that TreeTransform's use of remove_recursive would
be redundant.

For the case of unversioning, TreeTransform cannot unversion an entry
without unversioning all its children, so remove_recursive would degrade
to remove.

For the case of moving an entry, TreeTransform would remove all the
entry's children, only to add them all back later (except any that had
been unversioned), in the apply_insertion phase.

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


More information about the bazaar mailing list