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 "Ev2" by GregStein
Date Fri, 28 Jun 2013 18:58:16 GMT
Dear Wiki user,

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

The "Ev2" page has been changed by GregStein:
https://wiki.apache.org/subversion/Ev2?action=diff&rev1=8&rev2=9

Comment:
expand, with some thoughts that were generated during daniel/my IRC conversation

  
  http://mid.gmane.org/20130627100619.GA3011@lp-shahaf.local ''(near the end)''
  
+ Consider a simple swap: `rotate(A, A/B/C)`. There are a couple definitions of how this
+ swap might be performed:
+ 
+  1. A is reparented under B, B is reparented under C, and C is reparented at the root.
+  1. C/B exists and A is reparented there, and C is reparented at the root
+ 
+ Either definition is possible, but the natural ambiguity leads us away from
+ this solution. The "all-move" approach is much more transparent:
+ 
+  1. move A/B/C@original to A@new
+  1. move A/B@original to A/B@new
+  1. move A@original to A/B/C@new
+ 
+ It is now quite obvious that we are affecting three nodes, rather than an apparent
+ 2-node swap.
+ 
+ '''NOTE''': moves' source path must be defined against the original state
+ for this approach to work.
+ 
  == Make the SRC argument move `move()` relative to the start state, rather than to the current
state ==
  
  It's not possible to represent the time traveler otherwise: by the time the new A gets installed
in the tree, A/B@start no longer has a name in the being-edited ("in-flight txn") tree.
+ 
+ '''gstein''': the "no longer has a name" problem can be fixed by using `rotate()` (but see
above for a definitional problem with rotate)
  
  http://mid.gmane.org/20130627100619.GA3011@lp-shahaf.local ''(in particular, first paragraph)''
  
@@ -72, +93 @@

  
  See also http://mid.gmane.org/20130625223945.GG4806@lp-shahaf.local for some history
  
+ When switching to use the original state for the move source, it implies
+ the Receiver must have access to the original state. Consider the
+ following two moves:
+ 
+  1. move(A@original, B@new)
+  1. move(B@original, C@new)
+ 
+ The first move means that B@original is no longer in the current state. The
+ Receiver will need to locate B@original in some other way.
+ 
+ The FS editor can easily locate B@original from the appropriate revision root.
+ 
+ The WC's update editor has a much more difficult time. There are a couple
+ ways that the WC could solve this problem:
+ 
+  1. The incoming changes are placed into a client-side TXN. At the end
+     of the update, when `complete()` is called, the TXN becomes BASE
+     along with the regular post-update revision bump.
+  1. Each time a node is replaced (`SVN_IS_VALID_REVNUM(replaces_rev)`),
+     then the WC will set aside information about the replaced node
+     in case it needs to be accessed later.
+ 
+ Both the above scenarios will allow the WC to retain the original state
+ should it be needed for a later move.
+ 
  == Add a "replaced node's information" struct ==
  
- Anything that takes `replaces_rev` should take a struct describing the replaced node (when
there is a replaced node, i.e., it's a replace (possibly with history), not an add (possibly
with history).  It should include: replaces_rev, sha1 of replaced node (when it is a file),
tristate "will I refer to this node as a moved-from or copy-src ''later within this edit''".
+ Anything that takes `replaces_rev` should take a struct describing the possibly-replaced
node
+ (whether the replacement is performed using an add, copy, or move).
+ It should include: replaces_rev, sha1 of replaced node (when it is a file), tristate "will
I refer to this node as a moved-from or copy-src ''later within this edit''".
+ 
+ Note: if the operation is '''not''' a replacement, then the pointer can just be NULL (today,
we pass `SVN_INVALID_REVNUM` for `replaces_rev`).
  
  http://mid.gmane.org/20130627173345.GL2950@tarsus.local2
+ 
+ '''gstein''': I thought the SHA1 might be useful, but that would only provide
+ file contents. We'd still need to get the original properties from somewhere.
+ It seems that a WC-based receiver is still going to need to perform a lot
+ of work to preserve the replaced-node. As such, it might be easier to just
+ add the tristate, rather than create a structure.
+ 
  
  == Ambiguity: `add_symlink()` or `add_file()`? ==
  

Mime
View raw message