Discussion about merging

[Martin Pool]

On  3 Jun 2005, John A Meinel <john at arbash-meinel.com> wrote:
> I've been thinking about the bzr model, and how merging could/should
> work. One thing that keeps bzr from being really useful right now is
> that you can't keep your own tree, and just "bzr merge" the changes back
> and forth. As I understand it, bzr merge pretty just works when the
> ancestry is identical. (Which is a good start, make no mistake).

I think with Aaron's latest patch it will work as long as there is
some history in common, although it's not optimal yet.

> I'm thinking about the case where we are working on our own integration
> branch. So while we wait for mainline integration, we want to keep a
> tree with all of our patches, since they provide functionality that we
> want. 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.

Yep.

> My concern is that bzr records snapshots of the tree. And it doesn't
> really make sense to say "this snapshot was merged", it would make sense
> to say this patch/changeset was merged.
> 
> So really, when recording history, you need to record "I merged the
> differences between these 2 revision ids into the current tree".
> Maybe you could also list the in-between revisions. But since these are
> actually tree-snapshots, they are truly merged in the same way.
> 
> Is it okay in bzr to say that a given revision-id is both the
> tree-snapshot and the changeset between that revision and it's
> precurser? Since the revision-store includes the precurser, it seems
> like this might be valid.

You can say either of two different things.

"This revision was merged" implies that the full text of the revision
and everything leading up to it was merged.  Or "this patch was
merged".  Either can be useful, and different users might think of
different ones as primary.  To someone doing a merge using a tool like
dirdiff or meld they really are merging two trees; to someone working
with something like patch not so much so.

The big difference in merging a patch is that we don't necessarily
have to have merged all of its predecessors.

The other variation possible is 'cherry picking', which is arch jargon
for pulling out and applying just one changeset from another branch.
That may complicate later merges.

For the moment I want to just track what Arch does: the (ordered) set
of revisions that have merged into this branch.  (I don't think we
need to include the list of revisions actually on the branch; that can
be obtained simply enough from the revision history.)  Unlike Arch, we
can't rely on the revision names to determine anything about their
ancestry, but that is of course a bit fragile in the presence of arch
"tags" and continuations anyhow.

> Also, I know there was still discussion about whether a merge is
> presented as that specific revision-id in the revision history, or
> whether it would be stored as some sort of roll-up merge.
> 
> 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?

Yes, you have to do a roll-up merge -- also as for arch.  However,
there is one exemption, which is that when the last revision is X, you
can pull in any one successor to X without needing to do a roll-up
merge.  This allows an 'update' function when you're tracking another
branch without having introduced any changes.


-- 
Martin