[PATCH]: Optional explanation for options

[John A Meinel]

Robey Pointer wrote:
>
> 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.

Actually, that's not the way changesets are written. In order to apply a
changeset, you must have BASE. The changeset describes how to transform
BASE into TARGET, so that when you are done, you have an exact duplicate
of the revision being described.

Then that revision is merged against the current revision. This is where
fuzzy stuff and conflicts come into play.

So actually, the per-file and inventory and revision hashes are all
strictly enforced. It is just that once installed, the final merge might
generate a tree which has not existed yet. I hope that makes sense.

One of the interesting things, is that BASE can be anything. So I can
create a changeset of your tree, against mine, or a common ancestor, or
whatever makes the most sense. The default in the code is to take your
tree and find the common ancestor, and then produce the changeset that
will let you generate my tree from the common ancestor.

John
=:->

>
> robey
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050921/3ecafb56/attachment.pgp