[BUG] (trivial) duplicate text in "bzr pull --help"

[John Arbash Meinel]

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

Aaron Bentley wrote:
> Robert Collins wrote:
>>> The only knits for which caching is relevant during fetch
>>> is the inventory knit - the revision knit does not have anything other
>>> than the index retrieved until the revisions are fetched.
> 
> According to my log, inventory and revision knits both use the API
> inefficiently:
> 
> get_url http://michael.ellerman.id.au/bzr/.bzr/repository/revisions.knit
> [[(1801479, 1801975)]]
> add store entry 'michael at ellerman.id.au-20051127005141-3f22bf8da12129a0'
> added revision_id {michael at ellerman.id.au-20051127005141-3f22bf8da12129a0}
> readv coalesced 1 reads.
> get_url http://michael.ellerman.id.au/bzr/.bzr/repository/revisions.knit
> [[(1801976, 1802417)]]
> add store entry 'michael at ellerman.id.au-20051128062455-9da2ff70dd70e65c'
> added revision_id {michael at ellerman.id.au-20051128062455-9da2ff70dd70e65c}
> readv coalesced 1 reads.

I mentioned this in the past, and I think Robert said it was only part
of the upgrade code. I'm not really sure.

I think it is because some higher level operation is only requesting 1
revision at a time, even though it already knows about a whole bunch.

Looking closely at the code, it seems like we always pull all of the
file texts in all Fetchers. The Knit fetcher only is intelligent about
fetching revisions.knit and revision-sigs.knit.

The GenericRepoFetcher uses a loop over the revision_ids and fetches
them one by one. So probably that could be updated to call
get_revisions() instead of get_revision() many times.

There is no multi-call (yet) for get_signature_texts(). But that could
easily be implemented.

I'm pretty sure that get_revisions() is a Repository API, that is
implemented in all cases (it can just loop over get_revision() if that
is all that is available).


> 
> 
>>>> But I don't think we have a cheap way of finding out
>>>> whether the shortcut of copying knit records will create different
>>>> annotations from those that would be produced by rediffing.
>>>
>>> I think annotations should be considered a cache, and possibly invalid -
>>> simply because different diff() routines will generate different
>>> annotations, so if a specific annotation style is needed one should
>>> reannotate.
> 
> I think that would have some nasty side effects.  We would always have
> to reannotate before performing a knit merge, because we can't expect
> good results if the annotations are invalid.
> 
> Aaron

I think the cached annotations can be considered 'as good as can be
done'. Such that we realize re-diffing might return a different output
(especially when changing diff algorithms).
But at the time of creation/upgrading it was the best we could do.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEos9OJdeBCYSNAAMRArvZAKDDfiLSm0X/a3vjBZtY/aWmqB4CZACgy70u
TzvrMF8ClwI5u17wU/9OMK4=
=j2a3
-----END PGP SIGNATURE-----