Discussion about merging

Aaron Bentley aaron.bentley at utoronto.ca
Fri Jun 3 22:17:05 BST 2005

Hash: SHA1

John A Meinel wrote:
|> 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.


| 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.

| 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.

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

They just describe a way to find the common merge in the ancestry of
either branch without tracing the entire ancestry of either branch.

|> 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

Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the bazaar mailing list