Changesets and multiple ancestors

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
> Aaron Bentley wrote:

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

Sure, but as long as you can produce the other revision, it doesn't
matter what it is-- the changeset is merely a representation of K.

> 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),

It's not applyable to an I tree.  You can only merge it into an I tree.

> but I could not apply it
> on *my* tree, since I don't have the snapshot for G.

We may just be using different terminology, though.

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

It's not very satisfying to me.

I'd like changesets to be seamless, but it seems like if you always use
changesets, you'll eventually get screwed.  Of course, sometimes
'perfect' is the enemy of 'good', and sometimes 90% isn't even half as
good as 100%.

It seems we end up with two classes of ancestors: the ones in the branch
revision history, which are expected to be present, and those listed in
the revisions, which may or may not be present.

That will make things ugly in the branch and pull code, since missing
revisions are currently treated as fatal errors, and must now be
tolerated some of the time, but not all of the time.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCwYx30F+nu1YWqI0RAmmuAJ9tyULjijDjg+KckV56iR+2BRtajwCbBLU4
bEDUw4B9XXBeIeEKik0DlQI=
=BGl8
-----END PGP SIGNATURE-----