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

[Aaron Bentley]

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

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.


>>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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEosgB0F+nu1YWqI0RAvbkAJ48ReQ1lU13SwFitPfzLrN5H2dgCQCgh5k8
jeDQLAZb1QaK4jxNmmo2E24=
=V4sV
-----END PGP SIGNATURE-----