Changesets and multiple ancestors

[Aaron Bentley]

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

John A Meinel wrote:
> Aaron Bentley wrote:

>> I think treating merged revisions as ancestors makes changesets an
>> inferior way to merge.
>>
>> Changesets represent a single revision.  When you merge them, there's no
>> sure way to get their ancestry.  Which means that you wind up with
>> incomplete ancestry in your branch.
> 
> 
> Since bzr is tree snapshot focused, I think you are always going to lose
> something from a changeset. But it isn't very hard to have multiple
> parents listed.

I probably should have had some coffee before writing that.  I meant
that you don't have access to complete revisions for the whole ancestry.

> As discussed on IRC, a given revision_id represents a fixed tree state,
> including ancestry. So saying one of this revisions parent is XYZ
> implies all of the ancestry of XYZ. Even if you don't store that
> ancestry locally.
> Admittedly it is trickier to determine what your complete ancestry is.
> For example:
> 
> If my development line is:
> A - B - C - D - E
> 
> And you branch me at B
> A - B - C - D - E
>    |
>    + - F - G - H
> If I merge you back,
> A - B - C - D - E - I
>    |             /
>    + - F - G - H
> 
> All 'I' has to report is that 'H' is his ancestor. Which implies that
> F,G are also ancestors.
> 
> Now, it gets a little tricky if I someone else branches at some other
> time from you:
> 
> A - B - C - D - E - I - L
>    |             /     |
>    + - F - G - H      /
>            |         /
>            + - J - K
> 
> For 'L' you would want to realize that you have already merged in 'G',
> and that should be used as your base.

Yeah, so the first problem is determining that G is the best candidate
for a base.  The second problem is actually acquiring a copy of G.

> Isn't that what the "merged-revisions" file is for (or at least
> something like it)?

As far as I know, merged-revisions is obsolete, but it would be possible
to store this data in a fairly compact format:

B: A
C: B
D: C
E: D
F: B
G: F
H: G
I: E H
J: G
K: J
L: K I

>> We could have changesets represent multiple revisions, but that would
>> reduce their readability.
> 
> 
> I don't think it would substantially reduce it. First, for a normal 'I'
> changeset, you can just include both parents, and then a field for
> "merged revisions".

I don't think we're talking about the same thing.  I'm saying that if
you merge H from my branch, you can easily snag complete revisions for F
and G at the same time.  You can't do that if I mail you a changeset for
H-- you only get H then.

> I also don't see why I can't create a rollup changeset of E-L, which
> just lists the combined effects of all changes.

You certainly can, but that's not as nice as being able to get the
revision for every ancestor of L.

Let's look at you merging H instead.

To send you a changeset for H, I create a changeset that represents H,
relative to some revision that I know you have.  Could be E, could be B,
or anything else in your branch.

But it's just a representation of H, not F and G.

Now, we could restructure changesets so that they contained complete
revisions for ancestors missing from the target branch.  So there'd be a
way of constructing the F tree, and the G tree, and the H tree.

Probably you represent F relative to B, G relative to F, H relative to
G.  That's what I was saying would be less readable, because you can't
see easily what the result will be, compared to a roll-up.  In some
cases, revision-by-revision will be more readable, but it will depend.

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

iD8DBQFCwXEJ0F+nu1YWqI0RAutTAJ9xONPRR3xd4cvyIQru6Rx/c9GAsACfa62x
WN3XXTQ7CYXJf0HOZi4KYL0=
=RUhU
-----END PGP SIGNATURE-----