Merging (was: 7 times "Re:")

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas wrote:
> The merging, on the other hand is something new that hasn't
> to my knowledge been done in this type of space - maybe we could
> write an article on that once done.

Better first figure it out, then think about what to do with it. :-)

The main problem with merging is that it is functionality-dependant,
i.e. dependant on the semantics of the cells. Consider the following
case: Cells A, B, and C are connected on d.foo. One user changes this to
A, B, C, D; another user changes it to A, B, C, E. How to handle this
depends on the semantics of d.foo.

If d.foo is a list dimension, like d.cursor-list, then the resulting
rank should be e.g. A, B, C, D, E. Here we know that the order of D and
E doesn't really matter. If d.foo is like d.cursor, on the other hand,
where each connection is individually important and the rank as a whole
has no meaning, then D and E are in a conflict that must be resolved by
the user. Except that if we know about cursors, we can realize that
it'll suffice to make the connection C, D and then connect E to D on
d.cursor-list. If d.foo is d.clone, we can make the rank A, B, C, D, E
if in both of the users' versions, A has the same content. If the
content of this cell was changed, though, not only are these contents in
conflict, but the connection of D and E might be, too. Or not. That
depends of the specific use of cloning. If d.foo is a dimension for
which the tailcell has special significance, the two changes are in
conflict, but in how many dimensions is the tailcell special? Only in a
few ones. Maybe whether the tailcell has significance can only be found
out by looking along d.bar. Maybe their connections along d.baz will
reveal that D and E say in fact the same thing, and only one of them
should be kept.

These issues are why I have for some time argued that the system should
only support bringing the different versions into the same space, and
merging should be an action done by the applitudes.

-b.