[PATCH]: Optional explanation for options

[John A Meinel]

Martin Pool wrote:
> On 20/09/05, John A Meinel <john at arbash-meinel.com> wrote:
>
>
>>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.
>
>
> Another approach, which lifeless has advocated, is to transmit the
> actual changes as a binary blob attached to the message, and a
> human-readable diff just as a summary.  This has some strengths and
> weaknesses:
>
>  + does not require submitter to have published a public branch

Neither does an appropriate changeset.

>  + no chance of whitespace mangling

Sure, though I'm guessing inline gets mangled more often than attachments.

>  + can (optionally) compactly include a whole series of intermediate
> revisions, as well as the final result

My changeset can do that, though you lose the intermediate inventories.
If you wanted to keep them, you can either do multiple changesets at
once, or update the changeset spec to include it. (You have to know
which diff goes with which revision)

>  + can include gpg signatures for revisions, with no chance of them
> being damaged

This ultimately just depends on how we do gpg signatures for revisions.
But I think a single line of:
# gpg signature: blah-de-blah-de-blah

Would still be fine.

>  + the human readable diff doesn't need to show any ids or hashes

True.

>  + can patch binary or non-ascii files

Also true, though the changeset could also fall back on base64 encoding.
I believe the current changeset spec has everything done in UTF-8, so
you still would be able to handle non-ascii.

>  + we can check the diff is plausible (perhaps modulo whitespace)
> compared to the result of applying the binary change

I would put this as a "-" rather than a plus, since you need to do the
check. And I think it is a genuine weakness, since you are handwaving
some text, and then actually applying what is in the binary blob. So
what the human reviews is only close to what actually gets applied.

>  - some people would find the attachment ugly

Some feel attachments are ugly. Certainly emailing binary tarballs is
hard to parse.

I can understand that you might want patches inline, because then you
can review them from your mail agent. My mail agent (Thunderbird)
occasionally figures out that an attachment is actually text, and will
display it for me. But sometimes it just leaves it as an attachment (and
then I have to spawn an external editor).

But when it works, it does mean that I can review everything easily.

>
> I seem to recall people doing something like this with bk, but it does
> not seem common on the kernel archives (maybe because they disliked
> the attachments.)
>
>
>>One outstanding change that needs to be made is to remove the text-id of
>>files, and make them known (based off of the last revision which changed
>>them). That way they don't have to be transmitted.
>
>
> This is done in my newformat branch.  The tools/history2weaves.py code
> calculates these versions for imported data.  (I am soon going to run
> that code from the upgrade command instead.)
>

Does that mean that text-ids are going to change (and thus all of the
hashes of inventories, etc). Or just that the new text-ids will follow
the standard?

John
=:->
-------------- 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/20050920/916b85d8/attachment.pgp