Philip Martin wrote: > Greg Stein <gst...@gmail.com> writes: >> [from the Wiki] >>> Given these constraints, not all combinations of moves can be expressed >>> using a "move source to destination" operation, with or without a "rotate" >>> operation, without using temporary paths. >> >> I'm not buying that you need two operations. The "move uses initial >> state" tweak seems fully adequate and gets us the single-op/atomicity >> principle that Ev2 was designed under.
Hi Greg. I've given these issues a *lot* of thought over the last couple of months and have come up with some schemes which are close to being well defined, though the impedance mismatch between the existing purely path-based semantics and the "line of history" concept that's needed to define the whole idea of "moves" is a big obstacle. I have not been able to work the "move uses initial state" idea into a real scheme, and I think that's because it's not such a silver bullet as it sounds. I am not saying it's not possible to come up with some scheme that incorporates the idea, but referring to it as a "tweak" that "seems fully adequate" does nothing to help its cause. Without a hard spec, I'm sorry but it's just wishful thinking. Philip wrote: > At some point we have to create temporary locations and I suppose it > might be possible for the receiver to generate them as necessary. > However I'm still struggling to understand the ordering of moves and > alter_dirs so I can't determine whether that is practical or sensible. > > Given this example: > > svn mv A X > svn mv X/B/C A > svn mv X/B A/B > svn mv X A/B/C > svn ci > > or the equivalent: > > svn mv A/B/C X > svn mv A/B X/B > svn mv A X/B/C > svn mv X A > cvn ci > > we have this set of Ev2 moves in some order: > > move A, A/B/C > move A/B, A/B > move A/B/C, A > > What is the correct order for these operations? I guess there may be > more than one valid order since I showed two possible temporaries, > perhaps both > > move A, A/B/C > move A/B, A/B > move A/B/C, A > > and > > move A/B/C, A > move A/B, A/B > move A, A/B/C > > are valid. Or perhaps the alter_dir ordering rules exclude one? > > What about alter_dir? I think the rule is that alter_dir on a directory > should occur before add or delete affects the children of the directory. > There is also a rule: > > * - The ancestor of an added, copied-here, moved-here, or > * modified node may not be deleted. The ancestor may not be moved > * (instead: perform the move, *then* the edits). > > It's not clear where alter_dir should occur w.r.t the moves in my > example. Does alter_dir count as an edit that should occur after move? > Do we pass initial state paths: > > alter_dir ., children='A' > alter_dir A, children='' > alter_dir A/B, children='C' > alter_dir A/B/C, children='B' > > or final_state paths: > > alter_dir ., children='A' > alter_dir A, children='B' > alter_dir A/B, children='C' > alter_dir A/B/C, children='' Quite. I have come to the conclusion that all of these kinds of questions stem from the fact that the existing Ev2 rules were written with a path-based perspective. In order to talk rationally about moves, it is necessary to introduce a lines-of-history concept at least somewhere in the thinking behind the model. I have been through numerous possible adaptations of the "alter before editing" and "once rule" ideas to a move-aware world, and the best I have been able to achieve is currently documented in the Wiki here: http://wiki.apache.org/subversion/MoveDev/Ev2MovesDesign If you are willing and able to review that and suggest the necessary fixes that would be extremely useful. In parallel with that I've also been working on how we would extend Ev1: http://wiki.apache.org/subversion/MoveDev/Ev15MovesDesign which has the same path-based/line-of-history impedance mismatch problems but is easier to work with because the starting point is known and understood. - Julian
