Changesets and multiple ancestors

[John A Meinel]

Aaron Bentley wrote:

> Hi all,
>
> 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.

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.
Isn't that what the "merged-revisions" file is for (or at least
something like it)?



> 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".
If you look back at my proposed changeset format, I have minimal meta
information at the top, and then a bunch of extra meta-info at the
bottom. Specifically so that a human reading the changeset doesn't get
bogged down with a lot of arcane text, but it is all there.
Merged revisions can certainly go down to the bottom.

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. Though I agree, I don't
like that as much. You would want to develop some way of being able to
tell which revision merged what to get the ancestry graph correct.
Rather than just listing everything that was merged. But if you ever
actually come in contact with those revisions, you can tell what merged
what, since it is all contained in the <revision> file.

>
> Or we could say that it's fine to lack some ancestry in a branch, but
> that would still mean merging from branches was superior to merging from
> changesets.

This may always be the case, but I think you can get pretty expressive
in a changeset, and still have it viable for human consumption. You
might be missing the specific ancestry pointers, but you know what nodes
you have. Certainly you could say that for each "merged revision" you
should keep enough information to generate it's <revision> entry. Not
the full <inventory>, but such that your <revision> is the same as if
you pulled it in normally.

>
> So I don't see any easy answer.  Just food for thought.
>
> Aaron
>
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/9898eb2e/attachment.pgp