On Sat, Aug 06, 2005 at 09:31:06AM -0400, Kevin Smith wrote:
I really look forward to hearing comments from some of the SCM experts.
Is there a reason you didn't post this to the revctrl list as well?
Just that I don't want to embarrass myself and waste people's time if
this turns out to be
* Nathaniel Smith:
(One horrible idea I had, suitable for scaring small children who are
interested in merge algorithms: since it seem like trees may actually
be _easier_ to merge than text, by passing to the representation
of nodes-and-pointers-to-parents and then applying a nice scalar
Nathaniel Smith wrote:
(One horrible idea I had, suitable for scaring small children who are
interested in merge algorithms: since it seem like trees may actually
be _easier_ to merge than text, by passing to the representation
of nodes-and-pointers-to-parents and then applying a nice scalar
Bram Cohen wrote:
a
/ \
/ \
bb
|\ /|
a \/ a
| /\ |
|/ \|
bb
On both sides we have one do and one implicit undo, so both sides merged
clean to 'do', but when you put them together there are undos of both dos,
so the result should clean merge to a, even though both
On Sun, Aug 07, 2005 at 01:06:50AM -0700, Nathaniel Smith wrote:
Hmm, in traditional cdv tree-merging, all merges are marked the same
-- if the name is totally new, it's a new change; if it has the same
value as a parent, it's not. _Because_ of this, it hits ambiguous
clean in some simple
Kevin Smith wrote:
a
/ \
/ \
Xb Pb
|\ /|
Ya\/Ra
| /\ |
|/ \|
Zb Sb
It looks to me like when Y and P were merged to create Z, someone
specifically chose b over a. Same for RX-S. So two different mergers
chose b over a. b should win.
Ah, but going back a step, I see that
