[PLUGIN] bzr changeset now support rollup changesets (and bzr send-changeset)

[John A Meinel]

Michael Ellerman wrote:

>On Wed, 29 Jun 2005 08:37, John A Meinel wrote:
>
>
>>This is more just a test to get some feedback about the changeset
>>format. Whether people like it or not.
>>
>>
>
>I tried your code out the other day, and meant to comment, but been busy.
>
>I guess the format's not bad, it's just very verbose. It'd be nice to see if
>we can make it look a bit less like d9ce4223dad666352107900779c8142fc5915ae9.
>
>At a quick glance it doesn't look like there's much redundant information in
>there, so perhaps we really need all that guff.
>
>Maybe we'll have to have a "bzr changset --stripped" which throws away all but
>the essentials. There's no way I'd get away with sending the current format
>to LKML.
>
>cheers
>
>
We already have the stripped version. Basically just:
bzr diff -r <baserev> | mail lkml

The problem with that form is that it doesn't track any meta information.
The only thing that is different between it and "diff -u -r orig mod" is
that it will mark renames in a nice way, though not in a format that can
be applied with patch.

There is a small bug that timezone should not have 9digits of precision.

This looks a little noisy, because I rolled-up 2 small patches. So the
meta-info seems to dwarf the actual patches.

You also could technically leave off the footer. You lose the ability to
exactly recreate the change on the other end, but it would look nicer. :)

The basic point was that stuff for humans to read was before the patch
in the header, and stuff for bzr was all contained in the footer. So
while your eyes tend to gloss over when looking at it, that's why it is
all down at the end, after the stuff that you would want to look at.

Actually, if you look at what Robert Collins was mentioning, we need to
be even more verbose, so that you contain the individual changesets.

One thing that might solve both problems would be to do something like
create a small header + summary patch which is included inline, and then
all the extra meta-information, and individual deltas are stored in
something like a tarball. Then you still get the ability to read a nice
summary, and never have to see the real internals.
The default could be to name it something like "revision.cset" and
"revision.tar.gz". So that when you go to apply, it looks for the
associated tarball, if it doesn't find it, it complains, and maybe lets
you apply what you have.

Would that be a decent tradeoff? You have to make sure people save both
files into the same directory, but it prevents from cluttering the
display, and lets you add as much as we need.

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/20050628/8414a156/attachment.pgp