Discussion about merging
aaron.bentley at utoronto.ca
Fri Jun 3 22:17:05 BST 2005
-----BEGIN PGP SIGNED MESSAGE-----
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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar