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

[Aaron Bentley]

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

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>> I'm also looking at some penance.  It seems knit caching was used
>> 1. for converting weaves to knits
>> 2. for fetching knits
>>
>> So those things need to be fixed to avoid performance regressions.
> 
> Sure. Is it possible to add a benchmark for them, *ducks*. :)

Already in progress, dude.  Quack.

> Actually, it shouldn't be that bad. Just add a parameter to the
> 'make_heavily_merged_tree' which lets you set the format, and then
> create one with Weave format, and then upgrade it to Knit format, and
> see how long it takes.

To be an accurate simulation, those commits need to have file changes.
But yes, we can build that stuff in as optional.

> It has been discussed to remove the 'sha1=' field from Revisions, and
> change it to a 'testament_1_sha1'. Then we could do lots more integrity
> checking, and doing signature validation becomes relatively cheap. If we
> already checked the testament sha1 when we inserted the data, we don't
> have to re-build it just to check the signature, just grab it out of the
> revision entry.

Well, I'd acctually prefer to use a StrictTestament if we were doing
that, which would not help signature validation.  But knits feel like
the wrong layer for this stuff, to me.

> I'm not sure the best routes for enabling validation while maintaining
> good performance. But I would really like to see integrity checking
> before we copy knit hunks into our local storage

We can do that already, if by 'integrity checking' you only mean 'making
sure that the data is self-consistent'.  That seems like the right
promise at the knit layer.

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

iD8DBQFEo8H00F+nu1YWqI0RArhpAJ4poZ1Vhyrn0mJmB/M1ssdivx8cvACfUoAV
PSVLl7GCuGFctIYRzijYk+M=
=0dbK
-----END PGP SIGNATURE-----