Re: [zzdev] Merging (was: 7 times "Re:")

[Tuomas Lukka <lukka@xxxxxxxxxx>]

On Sat, Feb 24, 2001 at 10:36:22PM +0100, Benjamin Fallenstein wrote:
> 
> 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. :-)

That was just my way of saying that this is an 

	- interesting
	- intricate
	- important

problem.

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

Oh, definitely. But not only by the applitudes: user interaction at the same
time is vital.

The problems:
	- making it easy for applitudes to specify behaviour
	- showing (what types of views) the differences betweeen versions
	- allowing the user to select pieces of this and pieces of the other
		version
	- making sure that e.g. undo works well all during...
	- giving the user (on a single rank) the most important changes
		in applitude views

Did I miss any?

	Tuomas