Julian raised a question when I saw him in September: how does Ev2 deal with a node swap? ie. swap the contents of A and B, retaining metadata that they were moves [rather than copies from history].
In Ev2, we attempt to disallow "mv A B ; mv B C". The semantics around the interface say you should just do "mv A C". But to accomplish an A/B swap, you must "mv A temp; mv B A; mv temp B". Thus, A -> temp -> B, which is nominally disallowed in the Ev2 interface. Question: how to resolve this, given that we're starting to record *move* information? (the current interface could do: mv(replacing) A B; copy B@REV A) I've been thinking about a "multiple move" API to describe these kinds of changes. It isn't just a simple swap, since you could rotate content through an arbitrary set of N nodes. Suppose we had an interface that specified N nodes, and node[i] is moved to node[i+1], with the last one moving to node[0]. Would this be sufficient? I suspect that any moves *outside* of this ring uses the standard interface -- it is not participating in the rotation. Hrm. Maybe the API is named "rotate" rather than multiple move. (I say rotate because I'm envisioning the larger case where you have (say) 5 nodes, and each piece of content rotating to the next; looks like a clock or musical chairs) I'm not a master of topography or graphs, but I suspect that any given permutation of N nodes can be reduced to a set of rotations of subsets of those N nodes. Thus, a general "rotate" API should be sufficient. Cheers, -g ps. there is a corollary, unstated question of whether these kinds of rotations/multiple-move can be recorded in our WC schema.
