PreviewTree.inventory, and iter_changes

[Martin Pool]

2009/7/23 Robert Collins <robertc at robertcollins.net>:


All the logic up to this point makes sense to me.

> I'm inclined to implement .inventory on PreviewTree, using a decorator
> approach - a PreviewTreeInventory which answers with the transform
> changes first, and after that falls back to the original tree's
> inventory. This seems like it would be pretty easy to me (after all
> PreviewTree.iter_entries_by_dir already knows how to get entries
> appropriately), and not intrinsically more expensive or problematic than
> having a method to get an arbitrary inventory entry. It also makes
> PreviewTree more like all our other trees, which I think is a good
> thing.
>
> I don't think a method to get a single inventory entry is any more or
> less 'not using the inventory' - if we take this route, all a user has
> to do is 'tree.get_entry(tree.root)'.children, and they can walk the
> entire inventory with precisely the same bugs implicit as if we
> permitted access to .inventory.

I think it is a somewhat smaller interface, and I'd tend to add this
rather than adding a PreviewTreeInventory.  Even though people can
walk over the whole tree and mutate the entries to cause havoc through
get_entry, I don't think it's going to tend to cause whole inventories
to be passed around or mutated quite as much as if they were offered.

Also, we already have a _get_entry on dirstate based trees, and to
avoid confusion I would recommend using get_inventory_entry or
something similar.

-- 
Martin <http://launchpad.net/~mbp/>