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

[Michael Ellerman]

On Wed, 29 Jun 2005 11:31, John A Meinel wrote:
> 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.

Right, so that's not really much good to me. It doesn't even include the 
changlog, I may as well just use diff.

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

Yeah I realise that. I played with your code though, so I've seen non-rollup 
changesets too.

> 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. :)

That sounds interesting. I guess I'm interested in what the trade-offs are, if 
we lose some bits of metadata what does that mean for the resulting tree.

> 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.

Yeah that's a good idea. I'm not sure revno/base-revno/revision/base need to 
be up the top though.

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

Yeah I've been reading that discussion.

> 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.

No that's worse than sending a slightly verbose, but still plain-text, 
changset. You want to be able to cut and paste, or simply pipe your mail and 
get sane results.

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050629/b0245e0c/attachment.pgp