What is per_inventory supposed to test

John Arbash Meinel john at arbash-meinel.com
Thu Sep 24 19:15:37 BST 2009

Hash: SHA1

So I've been looking at working on:
  (log dir is slow in development-rich-root)

And my first pass at it, is to improve the 'Inventory.filter()' command.
Right now it is always built on 'iter_entries()' which requires walking
all content, even though we only need a subset. (The final change will
probably be higher, but I figured this should be better, too.)

Anyway, I've implemented some of it, but figured it should be tested,
and 'per_inventory' seemed like the right place.

However, the first thing I noticed was that "per_inventory" only tests
plain Inventory objects. (It has a list of 1 scenario.)

When I went to update that, I found that CHKInventory doesn't act much
like Inventory for many operations.

For example, you can't just __init__() one with a root id, and then
mutate it with 'add_path()'.

I believe it was very intentional that CHKInventory not be a
mutatable-in-memory class. We would use Inventory for that, and then
turn that into CHKInventory when necessary. (or use
CHKInventory.apply_delta() to get a new CHKInventory that was a result.)

Anyway, so if I wanted to actually make per_inventory run against all
inventory implementations, I needed to switch to the 'per_tree' model,
which is where you build up some state, and then snapshot it with
"self.workingtree_to_test_tree()". (inv_to_test_inv()...)

But it also ended up meaning that I need to move a bunch of tests out of
per_inventory/basics.py into 'test_inv.py' since stuff like 'add_path()'
will probably never be implemented.

Does that seem reasonable?

Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/


More information about the bazaar mailing list