[MERGE] Cache inventory.knit so we don't download it twice

[John Arbash Meinel]

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

Robert Collins wrote:
> On Wed, 2006-07-19 at 12:54 -0500, John Arbash Meinel wrote:
>> Unfortunately because of how the content is walked, I believe we
>> really
>> *do* need to iterate in order.
>> That iter_lines_added... has an api decision that we always walk the
>> history in an explicit order. Otherwise when we annotate we can get
>> different results. (If a line is repeated, it may match differently if
>> history is sorted in a different order). 
> 
> iter_lines_added... was not meant to require a specific order.
> 
> I dont think its encoded in the api docs that it does a specific order.
> 
> -Rob

Well, there is a test that it reads from the file in order, and that the
returned text is in a given order. But I suppose that is only
read-order. The problem is that if we were truly reading from the file
in order, my last patch should be saving lots of memory, since it yields
the texts as it gets them if it can.

Anyway, I'm happy to switch to unsorted, as it really does help.

So the question becomes...

Can we change the api of read_records_iter? There are no callers of it
outside of knit.py (because _KnitData is a private class).
Does that mean we can change the api without deprecation?

John
=:->

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

iD8DBQFEv47aJdeBCYSNAAMRAgrdAJ9VY8CtXxAG8Yk+hRc1vevZ9nhUgQCgyUpC
Jrtuw4GuybM/pC313Ihjzsc=
=L4Qv
-----END PGP SIGNATURE-----