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

[Aaron Bentley]

John Arbash Meinel wrote:
> This was written by Robert, who is currently behind an SMTP intercept.
> On Wed, 2006-06-28 at 14:18 -0400, Aaron Bentley wrote:
> For each of these three joins, the InterKnit code path should kick
> in(knit.py registers this at import).
...
> While is designed to allow a single readv and writev.
> 
> I am guessing that your earlier optimisation work has pessimised the
> readv queries that are generated, leading to you seeing what you are
> seeing.

FWICT, that code path must not be firing, because we're generating
contiguous sequences, and they're not getting combined.  But I'll know
more once I start debugging properly.

>>>>I think annotations should be considered a cache, and possibly invalid -

>>>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.
> 
> 
> By invalid I dont mean 'wrong'.

Oh, by 'invalid', I thought you meant 'not internally consistent'.

> , I mean 'not as good as it could be'.

Yes, this is probably acceptable.  But I do believe that combining two
differently-annotated knits could produce annotations that weren't
internally consistent.

> Consider for instance the change in diff algorithm if/when we switch the
> knit sequence matching over to patience diff?

Sure.

But I think our reannotation situation is a bit broken, too.  Right now,
many lines in builtins.by are incorrectly attributed to
aaron.bentley at utoronto.ca-20050918214753-129f45a74b8af9f2

Say I were to reannotate, to fix this problem.  The next time I pulled
in a fulltext from bzr.dev, that fulltext would clobber the annotations
back into the incorrect version.

Aaron