Changesets and multiple ancestors
John A Meinel
john at arbash-meinel.com
Tue Jun 28 17:35:39 BST 2005
Aaron Bentley wrote:
> 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.
sure. But you can have the header for them included. Just not the full text.
> >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.
Sure. I'm just recommending that we include enough meta information to
re-create the <revision> entries for F and G. It turns out that we don't
have the Inventory for them, but we do know who their parents are, and
so we can know in the future that we would want to merge from G. in the
case of merging K. And while we don't have G in the local tree, the tree
with K does, and we can use it's version.
> 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.
Yes, you can always send 3 changesets F, G, H and ask to merge them all.
But I prefer the rollup style. Since it is for human consumption. And
many times you put stuff in at F and take it back out or refactor it a
lot in G because you want it to look nicer. H could be almost trivial,
while F & G have tons of testing code show up.
Yes, a changeset is not as nice as a tree->tree merge, because you don't
get all of the snapshots. But as long as you get all of the meta
information, I think functionality is not reduced.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 253 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050628/52784068/attachment.pgp
More information about the bazaar