Changesets and multiple ancestors

[John A Meinel]

Aaron Bentley wrote:

> John A Meinel wrote:
>
> >Aaron Bentley wrote:
>
> >>The behavior isn't as nice because when it's time to merge K, because
> >>the best base is G, and that's not available.
>
> >Except K has to have G because it branched from it.
> >Your local tree doesn't have it. But someone among the 2 does.
> >And if you generated a changeset, you've already done the work, and I
> >can just merge what you say to.
>
>
> If I send you a changeset for K, it does not provide a way for you to
> produce G.  It also doesn't provide a way for you to avoid using G.
> Remember that the changeset for K is equivalent to a tarball of the K
> working tree, plus appropriate metadata-- it's just an optimization.
> Unlike Arch changesets, bzr changesets are not supposed to be applied
> using inexact patching.
>
> Aaron

A changeset has to be against some other version. Yes if you send me a
G->K changeset, I cannot apply that to I, but if you send me a I->K
changeset I can.

But you are right, since the 'official' base between K and I is G you
could generate a G->K changeset, which should be theoretically applyable
to any I tree (since I has G as an ancestor), but I could not apply it
on *my* tree, since I don't have the snapshot for G.

So I would say, "Yes, branch->branch merging will always be preferred",
but changeset merging can still get 90% of the job done.

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/fa97cdda/attachment.pgp