[PATCH]: Optional explanation for options

[Robey Pointer]

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


On 19 Sep 2005, at 21:06, John A Meinel wrote:

> Robey Pointer wrote:
>
>> I think you're right that the best thing to do is to include a
>> verification hash (SHA1 or whatever) so we can detect munged patches
>> before trying to apply them... and encourage people to send   
>> changesets
>> as attachments.
>>
>
> Well, the current changeset code does verify that all of the hashes  
> are
> correct. But since we don't transmit the text hashes, it only  
> figures it
> out once it has generated the inventory, which also means that it  
> can't
> figure out which file is bogus, just that something is.
>
> Now, we could put a bunch more hashes into the changeset, but part of
> the goal was to remove as much noise as possible.

Yeah, what we were actually referring to was adding a hash to the  
patch metadata.  It would basically be a hash of everything between  
the bzr header and footer sections, used for validating that the  
patch didn't get corrupted in transit.  (Obviously the header and  
footer sections should be designed to not depend on formatting/ 
whitespace anyway.)

It's probably true that a lot of the noise could be condensed into a  
little base64 block.

In re checking the per-file hashes or the inventory hash: hopefully  
those would just be warnings, since applying a cset as a merge could  
often cause the hashes to be different.

robey

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)

iD8DBQFDMJRCQQDkKvyJ6cMRAs+nAJ9VqD6G/KE5gLyaxvNhQqUh80ZLpACeODAJ
LWYKYDDbj9zh/hv4rjsoxLM=
=79TU
-----END PGP SIGNATURE-----