Discussion about merging

[Martin Pool]

On  3 Jun 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:

> | 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.
> 
> My reading was that, too.  I can't say for sure what Martin has in mind,
> but I think he's moved away from that idea.  And I'm pretty sure it was
> from before Martin decided to be snapshot-oriented.

I don't think I've ever wanted that except for perhaps in the very
earliest discussions in London.  It'd be confusing to have a revision
mean different things in different trees.

> | In my head, this isn't perfect, because there are times where you want a
> | summary changeset.
> 
> Agreed.  Summary changesets are nice-to-have, especially when you can
> still dig up the original changesets if you like.

Yes, they are.

The main change I'd like to make from Arch there is to try to avoid
generating summary changesets when they have no semantics.  For
example, merely syncing my laptop with my desktop (where they use two
branches that move on the same path) should not generate a summary
changeset, but it does in Arch.

> |> 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.
> 
> Apparently they've updated a bit since Martin wrote that.  But AIUI,
> it's more of a two-way merge.  For each line, you find out whether A is
> a modification of B or vice versa.  So you take the modification.  But
> there are also cases where A and B each modified C, so you get conflicts
> there.

It's in practice a lot like a weave merge, and I think there are some
notes on that too.  You can do such a merge on top of the structure
we're discussing here, just by allowing the text merge to consider
more than three revisions.  One might need different data structures,
such as a weave, to be able to do it quickly, but that can be done as 
and when necessary.

-- 
Martin