Changeset

[John A Meinel]

Aaron Bentley wrote:

...

> Right.  So when you submit a changeset, you can use the other person's
> branch base as your changeset base.  That doesn't mean that they will be
> able to cleanly apply it.
>
> By requiring that the changeset base always be known to the receiver, we
> gain the ability to do three-way merging, which is better than
> patch+diff, because three-way merging can be done using patch+diff with
> custom options, or diff3, or wiggle, or meld, or pretty much any merge
> tool.
>
> This also simplifies changeset handling, because if changesets are only
> ever applied to their exact base, there can never be ambiguity or
> conflicts.

Okay, I think I've gotten my head around it, and am starting to agree
with you. I like the idea of changesets standing on their own, without
extra info, but you have a point that being able to expand them back
into the full tree state has some definite advantages.

>
> >It seems to me, that if a changeset is used to install revisions, then
> >we have the problem of needing to include *lots* of meta information.
>
>
> No, I think Martin's latest proposal is almost exactly right.  What data
> is missing?
>
> >Especially for roll-up changesets. To give you A->B->C->D I need to give
> >you the states for B & C, not just the delta from A->D.
>
>
> If you want to give me B and C as well as D, you have to communicate
> them somehow.  If you just want to give me D, you can send A->D,
> assuming A is a revision I have.

 From my understanding of what you want, the text that I email has to be
capable of reproducing B,C,and D, not just D and informing you that B
and C were part of the process.
I was hoping to make it so that the email could contain enough to
generate the revision XML for B, C, and D, and then a diff between some
base that you know about and the current state of D.
That will let you 'install' revision D, but not B or C. (bzr
apply-changeset blahblah-D)
If you have my tree sitting next to yours, you have the state of B and C
such that they can be easily installed when you go to merge D. (bzr
merge ../mine/@D)

This does cause changesets to be slightly less powerful than merging.
But they will always be so. Because at merge time, you could pick
whatever base you want, because you have the complete trees. Creating a
changeset fixes the base and target, but it does it so that you can
generate a small summary.

Still, I think this does interesting things to my changeset code.
Specifically the interface needs to change. Because now you need a way
of stating what revisions are involved, what you consider base, and what
you consider target. Frequently, I think revision[0] == base because
that is easy, but it isn't required.

The simplest interface would be to pass it information like merge. So
you say:
bzr cset ../other-tree/@rev
And it would make BASE = merge base, TARGET = ./@, and Revisions =
merge-base => TARGET
Alternatively (perhaps with a flag) it would make BASE =
../other-tree at rev, but leave target & revisions the same.

How does that sound?

You could also explicitly set target with something like
bzr cset ../other-tree/@rev ./@rev

You can generate one without another tree with a simple
bzr cset ./@90 ./@
Which would be fairly common, especially if you knew the exact revision
that you branched off of someone else.
In fact, it would be nice if bzr branch/pull recorded some sort last
pulled revision, so that a plain "bzr cset" would default to whatever is
considered the 'local' changes.
Between that and having branch copy the 'x-send-address' file you can get.
$ bzr branch http://bazaar-ng.org/bzr/bzr.dev
$ cd bzr.dev
<hack hack hack>
$ bzr commit -m "some stuff"
<hack hack>
$ bzr commit -m "some more"
$ bzr send-changeset

And the maintainer can look over the changes, and then
$ bzr apply-changeset
Without needing access to your local tree.
With any luck, a future
$ bzr merge http://bazaar-ng.org/bzr/bzr.dev
Would be able to merge with mainline without having any conflicts due to
mainline merging your changes.

I'm not sure how changesets start to work with potential cherry picking,
though.
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/20050629/ff261872/attachment.pgp