[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Merging (was: 7 times "Re:")
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Merging (was: 7 times "Re:")
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Sun, 25 Feb 2001 00:37:34 +0200
- Cc: ZZ Development <zzdev@xxxxxxxxxx>
- In-reply-to: <3A982956.AD93D25B@xxxxxx>; from b.fallenstein@xxxxxx on Sat, Feb 24, 2001 at 10:36:22PM +0100
- Mail-followup-to: Benjamin Fallenstein <b.fallenstein@xxxxxx>, ZZ Development <zzdev@xxxxxxxxxx>
- References: <20010223114609.A18335@xxxxxxxxxxx> <3A96DA92.FA0032F4@xxxxxx> <20010224115918.A32572@xxxxxxxxxxx> <3A979326.15B8DB20@xxxxxx> <20010224131831.A911@xxxxxxxxxxx> <20010224131240.F15568@xxxxxxxxxxxxxx> <20010224152828.A1257@xxxxxxxxxxx> <20010224170058.H15568@xxxxxxxxxxxxxx> <3A982956.AD93D25B@xxxxxx>
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
> 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.
- 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
- 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?