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: https://wiki.apache.org/subversion/Ev2#The_constant_grandchild:_.60swap.28A.2C_A.2FB.29.60_without_moving_A.2FB.2FB You might want to do the same with the questions you asked above, for the same reason. Cheers, Daniel > "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.
