Discussion about merging

[John A Meinel]

Aaron Bentley wrote:

> John A Meinel wrote:
> | My primary motivation for getting native plugin support added, was
> | because I can add functionality in a plugin, and then not have to worry
> | about a separate branch as much.
>
> Hear, hear!
>
...

> Anyhow, it's defined, but may not be in the revision store.  However,
> all we need is for it to be defined.

Sure, as long as it is defined, then revision id is both a tree snapshot
(by virtue of having an inventory-id) and a changeset (by having a
previous revision).

>
>
...

> | Because if you don't do the roll-up merge, then you have to merge each
> | step one at a time. But at no point do you genuinely have the same
> | tree-snapshot to correspond with the revision id. Doesn't that mean you
> | *have* to use a roll-up merge in any time where the ancestry is not
> | identical?
>
> If the ancestry is identical, you don't need merge.
>
> But you don't have to do roll-up commits, either.  You can do a series
> of commits, starting with the first descendant of BASE, and moving on to
> the next until you reach the most recent.

I'm saying that the revision id must be different. Even if you are only
merging a single entity, the final tree state is different. And since
revision-id => inventory, you should used a different revision-id.
I'm just pointing out that if I merge abentley at blah-2342-234-234234 into
my tree, I cannot call it abentley at blah-..., because the precursor needs
to be different, as does the inventory id.
Unless you are planning on somehow supporting having 1 revision id map
to 2 different inventories + precursor, as long as the diff between
precursor and itself is identical.

Maybe I just misunderstood the plan. From what I read, it sounded like
you wanted merge to show that the patch was merged almost as though it
had been generated there to start with. (you didn't want an extra
commit, you wanted 1 entry in revision_history per each merged
changeset). To me, this sounded like you wanted to preserve the revision-id.
In my head, this isn't perfect, because there are times where you want a
summary changeset. (eg revs 49-50 are good, 51,52 would conflict, but
this is fixed in 53. So you can merge 49-53 without conflict, but not
all the steps inbetween). If someone else branched from 51, and you try
to merge from them later, you don't want to select 51 as a base, since
it never actually existed in the current tree.

I have to read through your longer merge steps in case I'm missing
something.

>
> | I'm guessing this is some of the problems with using snapshots rather
> | than using changesets, but maybe I just have my head turned the
> wrong way.
>
> The one converts to the other rather easily, so use whatever makes the
> most sense in the problem space.  There's no reason this can't work
> exactly the same as Arch does.  (But we'd rather have it work the way
> Codeville does.)
>
I haven't used codeville, so I can't say much how it is different.
Though reading the documentation in bzr.dev/doc it sounds interesting.
The idea of each line having an independent base has some merit.
John
=:->

> Aaron

-------------- 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/20050603/1efaafa0/attachment.pgp