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

[Michael Ellerman]

On 7/20/06, Robert Collins <robertc at robertcollins.net> 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.

    def iter_lines_added_or_present_in_versions(self, version_ids=None):
        """Iterate over the lines in the versioned file from version_ids.

        This may return lines from other versions, and does not return the
        specific version marker at this point. The api may be changed
        during development to include the version that the versioned file
        thinks is relevant, but given that such hints are just guesses,
        its better not to have it if we don't need it.

        NOTES: Lines are normalised: they will all have \n terminators.
               Lines are returned in arbitrary order.
        """

The knit version of iter_lines_added_or_present_in_versions() actually
does the loop based on the order of version_id_records, which is
ordered as per self.versions() - so it doesn't respect the order of
version_ids passed to it anyway.

But I have no overall understanding of this stuff, so I'll leave it up
to you guys.

cheers