Full files in changesets?

[Martin Pool]

On Mon, 2005-04-18 at 12:10 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Currently, bazaar-ng doesn't have a changeset format.  If we're planning
> on adding one, it would be for code exchange, and wouldn't be used by
> the text store, as in Arch.
> 
> I wonder then, should it contain the full before and after texts of the
> files?*  The advantage would be for three-way merging.  It would allow
> the before-text to be used as the BASE and the post-text to be used as
> the OTHER.  So this would enable three-way merging, without requiring
> access to the THIS and OTHER trees used to generate the changeset.
> 
> The knock-on effect is that you reduce the number of operators.
> Everything is a three-way merge-- there's no 'exact patching'.

That is, there's no need to patch using only diff context.

(I've been using the term "exact patch" for when the patch arrives
before any other changes have been made after the revision it patches,
so THIS=BASE, and it perfectly fits in.)

> I have to say though, that reading patches in emails is a refreshing
> change from the Arch mailing lists, which simply say "the code to
> implement this is in foo at bar/baz--bzr--0".  So maybe adding changesets
> isn't even a good idea.

Isn't it nice?  There's definitely a good feeling about being able to
simply and directly see the proposed changes right there in the email in
the form that we're used to.

> *It's not actually necessary to include the full text of *both* files.
> A full copy of one, plus a patch to transform it into the other would
> suffice.

Taking this one step further: all we need is the patch and the id of the
basis revision, if we require that the recipient already have that basis
revision.  We can then generate the three texts and proceed.

This means that the person sending the patch must know something about
what revisions are possessed by the person receiving it, but I think
that's often reasonable.  In this case here they will send a patch
relative to some previous revision of my mainline, and all they need to
do is identify that.  In general if we generate the patch to send
against another branch, it will be OK.

So 

  bzr send --relative-to ~/work/bzr.devel ~/work/bzr.mine bazaar-ng at ...

This finds the greatest common point between them and sends a delta from
that.  (If there are several commits in bzr.mine then we might want to
generate a series of emails, as people do on the kernel list, etc...)

That command might be abbreviated by keeping a submission email address
in a checked-out branch, and having each branch send to its parent by
default.

A sketch of the format:

## bzr annotated diff
## you can apply this patch with "bzr receive" or "patch"
##
## revision-id: mbp at foo-2005010101055555-sajhdakjsdhkjahsdkja
## predecessor: john at bar-kasjdlkajsdlkjaskld-asdjhasdkjhasdhahd
## comments:
##   Here is my nice patch.
## date: 2005-04-01 12:34:23
## ....
##
## modified file
## file-id: hello.c-21983710231232-123123123189239789
## previous-sha1: 8098a09s8098a09809a8098098098
## sha1: 9218309182039102381093720372137
## directory: 2178389071238972139712978323
## path: src/hello.c
## ...
+++ src/hello.c
--- src/hello.c
0,0 at 1,1
 int main()
 {
+   hello();
 }

There is a bit of garbage but I think not so much as to offend the human
eye.

Obviously binaries need special handling.
 

-- 
Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050419/9d5b13e9/attachment.pgp