[MERGE] Add an InventoryEntry cache for xml deserialization

[Vincent Ladeuil]

>>>>> "jam" == John Arbash Meinel <john at arbash-meinel.com> writes:

    jam> Vincent Ladeuil wrote:
    jam> ...

<snip/>

    jam> Anyway, I'm guessing you missed my other email where I implemented (4)
    jam> anyway.

Yes, that and the comments from Martin and Robert, they came in a
later batch in my workflow that morning.

    >> 
    jam> Which helps for us to know that the caching rules won't
    jam> be violated. The main downside is that something that
    jam> ends up dealing with two mostly-identical repositories
    jam> will not benefit.
    >> 
    >> Should be rare enough to neglect. At worst, and only if really
    >> worth it, the two repos can negotiate to share their caches.
    >> 
    jam> The original use-case I was trying to handle is the
    jam> "extract all revision trees from the repository"
    jam> which works just fine here, but there are other use
    jam> cases where an entry cache would be helpful.
    >> 
    >> I'd love to have one for "bzr log -v"... but i"m pretty sure that
    >> in that case I'd love to be able to clear it (or at least purge
    >> it more aggressively), at various points.

    jam> There is always entry_cache.clear() for all of the
    jam> caches I've written.

I was wondering about an intermediate purge (not the default one
nor the full one).

    jam> But I'm wondering what your specific use case is. Or are
    jam> you thinking this is more something that is being
    jam> written to disk?

Something along the lines of: 
- I need the inventories for one revision and all of its parents
- I want to keep the first parent entries in the cache more than
  the other parents entries

So that I get the cache effect while processing the merged
revisions but keep my mainline entries still in the cache.

I'm thinking aloud here (I still don't have code to support such
a case, and I may never have), may be two caches will work better
(but can the serializer handle several caches at once ?).

<snip/>

On the tests front, far less failures but still some in
fast-import:
FAIL: bzrlib.plugins.fastimport.tests.test_processor.TestRename.test_move_to_new_dir
    [] is renamed
not equal:
a = 0
b = 1


FAIL: bzrlib.plugins.fastimport.tests.test_processor.TestRename.test_rename_in_root
    [] is renamed
not equal:
a = 0
b = 1


FAIL: bzrlib.plugins.fastimport.tests.test_processor.TestRename.test_rename_in_subdir
    [] is renamed
not equal:
a = 0
b = 1

Since they are around fast-import using an inventory for its own
purposes and apparently being tricked by the cache when trying to
handle renames, I'm not sure where the bug should be fixed, but
since I saw the test failures, I thought I should at least report
them.

  Vincent