subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "MoveDev/Ev2MovesDesign" by JulianFoad
Date Wed, 04 Sep 2013 15:50:44 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "MoveDev/Ev2MovesDesign" page has been changed by JulianFoad:
https://wiki.apache.org/subversion/MoveDev/Ev2MovesDesign?action=diff&rev1=1&rev2=2

Comment:
next part of new page

  
  [2] An example problem in thread [1], of swapping A with A/B/C: <http://svn.haxx.se/dev/archive-2013-06/0684.shtml>
or <[[http://mail-archives.apache.org/mod_mbox/subversion-dev/201306.mbox/<87bo6rewwp.fsf@ntlworld.com>|http://mail-archives.apache.org/mod_mbox/subversion-dev/201306.mbox/%3C87bo6rewwp.fsf%40ntlworld.com%3E]]>.
  
+ == Move-Away and Move-Here ==
+ One solution is to describe the two halves of each move separately:
+ 
+ {{{
+ move-away SOURCE-PATH
+ …
+ move-here DESTINATION-PATH
+ }}}
+ We can then solve Example 1 in the following way: issue the “move-away A”, then create
a new directory at path A which replaces that source of the move, and then finally issue the
“move-here A/B” which relies on that replacement directory A having been created.
+ 
+ The consumer must be able to put the node aside for an indeterminate amount of time until
the “move-here” is received.
+ 
+ Of course there needs to be a way to link each move-away with the corresponding move-here.
 Remembering that each edit step refers to the current state in a sequence of states, we cannot
simply specify the path corresponding to the other end of the move like this:
+ 
+ {{{
+ move-away SOURCE-PATH to DESTINATION-PATH
+ …
+ move-here DESTINATION-PATH from SOURCE-PATH
+ }}}
+ because the problem cases are when the destination path does not yet exist at the time of
a move-away, or the source path no longer exists at the time of a move-here.  What we can
do is use some other unique reference that is unique within the edit, like this:
+ 
+ {{{
+ move-away SOURCE-PATH as identifier ID1
+ …
+ move-here DESTINATION-PATH from identifier ID1
+ }}}
+ The reference could perhaps be the destination path as it will finally exist at the end
of the edit, or just an arbitrary number or string.  We will just specify the identifier as
an “id” and not specify how it is generated.
+ 
+ === Explicit Direct Moves ===
+ We could have distinct operations for direct and indirect moves:
+ 
+ {{{
+ move SOURCE-PATH DESTINATION-PATH
+ move-away SOURCE-PATH as identifier ID1
+ move-here DESTINATION-PATH from identifier ID1
+ }}}
+ In cases where the driver can issue a move(a,b) instead of a (functionally equivalent) pair
of move-away immediately followed by move-here, then the receiver is likely to be able to
process that single move more efficiently.  So having the three methods available is better
than just having the latter two.
+ 
+  . Brane wrote: [The inclusion of an explicit direct move] also makes validating the drive
easier.  Move away without a matching moved here (or the converse) is clearly invalid. It
must be trivial for the receiver to detect that.  Making the temporary locations explicit
makes that so much easier.  Regarding direct move without intermediate state, IMO the driver
should be required to to use that whenever it can.  Driver always has enough info to know
that receiver can process such a move.  If it cannot, that indicates a bug in the driver.
+ 
+ We should probably just leave it as a "quality of implementation" issue for the editor driver
to prefer single move(a,b) instructions over pairs of move-away, move-here.  We could try
to come up with a requirement that it must do so in certain cases (starting with collapsing
adjacent pairs of move-away, move-here), but I think this may be rather difficult to define
fully, and of limited benefit.
+ 
+ === Ordering Restrictions ===
+ The ordering rules regarding move-away and move-here should include:
+ 
+  * mv-away must come before the matching mv-here
+   * The edit should provide a sequential procedure that the             consumer must be
able to follow without having to buffer an             arbitrary amount of state.
+  * mv-here & cp & add must be in nesting order: create  (or put in place) the parent
before its children
+  * mv-away must come before deleting a parent
+   * Receiver needs to know that it must preserve this path when                 we delete
its parent.
+  * mv-away must come before mv-away of a parent
+   * If we allowed “mv-away A; …; mv-away A/B” then the          child path “A/B”
would have to be specified not relative to the                 current state of the edit,
as all other operative paths are, but in             some other way, because the parent has
gone into temporary              namespace, and has perhaps been replaced so that “A/B”
now              refers to some other node.
+   * There is a general rule that all edits within a moved               directory “A”
must come after A is moved its destination, but a                 mv-away of a subtree of
A is not considered an edit for this            purpose.
+    * ### Reconsider this rule.  s/must/may/ ?
+ 
+ === Examples Solved ===
+ ==== Example 1: Insert a directory level ====
+ {{{
+ |                     |
+ +--A  mv--\    add--> +--A
+            \             |
+             \-->         +--B
+ }}}
+  1. alter-dir / (children={A})
+  1. mv-away A (id=“original A”)
+  1. add-directory A (children={B})
+  1. mv-here A/B (id=“original A”)
+ 
+ ==== Example 2: Swapping two siblings ====
+ {{{
+ |                     |
+ +--A      --\ /-->    +--A
+ |            X        |
+ +--B      --/ \-->    +--B
+ }}}
+  1. alter-dir / (children={A,B})
+  1. mv-away A (id=“original A”)
+  1. mv-away B (id=“original B”)
+  1. mv-here A (id=“original B”)
+  1. mv-here B (id=“original A”)
+ 
+ Example 3 can also be solved in this way, except for some ordering restriction issues that
are discussed below.
+ 
+ Some further examples related to example 1.
+ 
+ ==== Example 1b: Remove a directory level (by deletion) ====
+ {{{
+ |                     |
+ +--A (del)     /-->   +--A
+    |          /
+    +--B  mv--/
+ }}}
+ The move-away must (in principle) happen before the delete, while the move-here cannot (in
principle) happen before the delete.  However, the Ev2 “add” and “copy” operations
are defined to perform a simultaneous “delete” when replacing an existing node, and so
the “move” operation could do the same and thus make this case trivial.  Compare with
example 1c.
+ 
+ ==== Example 1c: Remove a directory level (by move-away) ====
+ {{{
+ |                     |
+ +--A  mv-->?   /-->   +--A
+    |          /
+    +--B  mv--/
+ }}}
+ Here there are two approaches.  Either we move-away B, then move-away A, then move-here
B (to path A); or we move-away A, then move-away B (from its temporary path inside A, which
might currently be in limbo), then move-here B (to path A).
+ 

Mime
View raw message