[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Ev2 as a move-aware editor

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Mon, 1 Jul 2013 15:32:59 +0300

Julian Foad wrote on Thu, Jun 27, 2013 at 18:42:18 +0100:
> For the record, to make it easier to understand our current position in retrospect, I'll try to summarize our findings about the 'rotate' operation so far.
> We started with a requirement:
>   * Represent with 'true moves' any combination of moves that can already be represented using the copy-and-delete model in Ev1.
> We assumed some constraints:
>   * A sequential model with operations including 'move' and 'rotate'.
>   * Don't touch a path more than once.
>   * Don't use temporary names/paths.
> We found:
>   * Examples with no solution that fits the constraints.
> But:
>   * We did not define 'rotate'.
>   * We did not define 'touch'.
>   * We did not define 'path' in the context of 'touch a path'.
>   * We have only hinted at the rationale for these constraints.

> What
> if (B) has a child named "B" already?  Two possible options are the
> rotation is not allowed or the child gets deleted and replaced.  These
> options both impose an additional ordering constraint: if we want to
> keep that node and move it to somewhere else, we have to do it *before*
> this rotation.  But there are cases where we cannot do that.  Perhaps
> the simplest is swapping 'A' with 'A/B' while keeping 'A/B/B' in place:

I didn't understand your diagrams, but I went ahead and added this
example to the Ev2 wiki page so we don't forget it:


You might want to do the same with the questions you asked above, for
the same reason.



>   "A" |   --  -> "A" |
>      (A)    \/      (B)
>   "B" |     /\   "B" |
>      (B)  --  ->    (A)
>   "B" |          "B" |
>      (B2) ----->    (B2)
> Note
> that node (B2) needs to be 'moved' although it remains at the same
> absolute path, because our definition of 'move' says that it would
> otherwise go with its parent.  In this case, we cannot move A/B/B before
> the rotate because it would need to go to A/B which is already
> occupied.  If we try to do it after the rotate, we find it has already
> been deleted and replaced, as explained in the previous paragraph.
> Thus the model does not satify the constraints.
Received on 2013-07-01 14:33:36 CEST

This is an archived mail posted to the Subversion Dev mailing list.