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] Trivial Update of "MoveDev/MoveDev" by JulianFoad
Date Thu, 20 Jun 2013 20:33:52 GMT
Dear Wiki user,

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

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

- 
- 
  = How to Add Moves to Svn =
- 
  == Summary ==
  Subversion needs to handle moves and renames better than in version 1.8.  This paper presents
the rationale and a plan for doing so.
  
@@ -29, +26 @@

  
  Some previous ideas about how much we need to track moves explicitly:
  
-  * We need to track moves in the server so we 	can do forward history tracing.  But does
this really help unless 	the clients are aware and able to communicate these moves to and
	from the server?
+  * We need to track moves in the server so we   can do forward history tracing.  But does
this really help unless       the clients are aware and able to communicate these moves to
and        from the server?
-  * Track moves in the WC only – as implemented 	in Subversion 1.8.  This helps with certain
situations: it can apply 	incoming edits into a locally moved node, and it can prevent the
	accidental committing of just one half of a move.
+  * Track moves in the WC only – as implemented  in Subversion 1.8.  This helps with certain
situations: it can apply    incoming edits into a locally moved node, and it can prevent the
       accidental committing of just one half of a move.
-  * We don't need to track moves explicitly, as 	we can do everything we really need by recognizing
copy-and-delete 	as a move, and that has the advantage of not changing the network 	protocols
and so on.
+  * We don't need to track moves explicitly, as  we can do everything we really need by recognizing
copy-and-delete      as a move, and that has the advantage of not changing the network   
   protocols and so on.
-  * We don't need to track moves explicitly, as 	we can do  everything we really need by
always treating a copy in 	the same way as the copy half of a move.  So, when merging, if
there 	is a copy of the node being merged, then all changes destined for 	the copy-source
node should go to the copy-dest node as well – or 	instead, if the copy-source node is deleted.
 In this way, the 	semantics of copy and move are unified.
+  * We don't need to track moves explicitly, as  we can do  everything we really need by
always treating a copy in       the same way as the copy half of a move.  So, when merging,
if there    is a copy of the node being merged, then all changes destined for       the copy-source
node should go to the copy-dest node as well – or       instead, if the copy-source node
is deleted.  In this way, the  semantics of copy and move are unified.
  
  Arguments against treating any copy in the same way as the copy half of a move:
  
-  * Why should we treat a single copy (cp A A2; 	rm A) differently from the same situation
plus an additional copy 	(cp A A2; cp A A3; rm A)?  And if we decided to merge into all the
	copies alike, then why should we only do so when there is a delete?
+  * Why should we treat a single copy (cp A A2;  rm A) differently from the same situation
plus an additional copy       (cp A A2; cp A A3; rm A)?  And if we decided to merge into all
the      copies alike, then why should we only do so when there is a delete?
  
   * ...
  
  === Combining Changes ===
  The problems with copy-and-delete boil down to various kinds of ambiguity, inconsistency
or non-determinism.  Many of these are related to the problem of representing a sequence of
changes as a single change.  It is fundamental in a version control system to be able to update,
merge or diff between two widely separated revisions without having to step through all the
intermediate revisions in sequence, and so it is necessary to have an unambiguous way of combining
successive changes.  If we attempt to interpret copy-and-delete as a move, that leads to ambiguous
or context-dependent results when combining changes.
  
-  * Spatial ambiguity.  When looking at a subtree 	that contains only one half of the move,
we would see a copy or a 	delete, but if we then look at a wider subtree we would see a move.
 	Look wider again, and we may see a second copy from the same source, 	which means there
is no move because there is no unique copy.
+  * Spatial ambiguity.  When looking at a subtree        that contains only one half of the
move, we would see a copy or a       delete, but if we then look at a wider subtree we would
see a move.     Look wider again, and we may see a second copy from the same source,    which
means there is no move because there is no unique copy.
-  * Ambiguity when the copy-from is not the 	revision immediately before the copy-and-delete.
 If the deleted 	node was modified between the copy-from revision and the delete, 	then is
it still a move?  No, because it has a forked history.  If 	we treat it as a move only if
the delete side was not modified since 	the copy-from revision, then there is a race on commit
because the 	change that gets committed will be seen as a move if nobody else 	modifies it
in the meantime, or as a non-move if somebody gets in 	first.  If we want the semantics of
a move, we have to tell the 	server it is a move so it can avoid this.
+  * Ambiguity when the copy-from is not the      revision immediately before the copy-and-delete.
 If the deleted        node was modified between the copy-from revision and the delete,  
     then is it still a move?  No, because it has a forked history.  If      we treat it as
a move only if the delete side was not modified since    the copy-from revision, then there
is a race on commit because the      change that gets committed will be seen as a move if
nobody else        modifies it in the meantime, or as a non-move if somebody gets in     
 first.  If we want the semantics of a move, we have to tell the         server it is a move
so it can avoid this.
-  * Ambiguity when the delete is not in the same 	revision as the copy.
+  * Ambiguity when the delete is not in the same         revision as the copy.
-  * Temporal ambiguity.  Difficulty in composing 	a series of changes (revisions) together.
 If we start with (cp A 	A2; rm A), that looks like a move, but if we then commit (cp 	A@orig-rev
A3) and look at the overall combined change, we now see a 	multiple-copies scenario.  Conversely,
if we start with (cp A A2; cp 	A A3; rm A) and then commit (rm A2), we change a non-move into
a 	move.
+  * Temporal ambiguity.  Difficulty in composing         a series of changes (revisions)
together.  If we start with (cp A       A2; rm A), that looks like a move, but if we then
commit (cp    A@orig-rev A3) and look at the overall combined change, we now see a    multiple-copies
scenario.  Conversely, if we start with (cp A A2; cp    A A3; rm A) and then commit (rm A2),
we change a non-move into a        move.
  
  In one context, a certain copy and delete can be paired uniquely and thus interpreted as
a move, while in another context the same copy and delete are not unique or are not both visible.
  
  === Move vs. Rename ===
  We say “move” or “rename” interchangeably for most purposes.  Their essential similarities
include the concept of a preserved node identity.  It can be useful sometimes to draw a distinction.
 When merging a rename-only (A/foo → A/bar) with a move-only (A/foo → B/foo) we can suggest
that the most likely merge resolution would be to apply both the move and the rename (→
B/bar).
  
- == H2 { margin-bottom: 0.21cm; }H2.western {  }H2.ctl { font-family: "FreeSans"; }P { margin-bottom:
0.21cm; }P.western {  }A:link {  } ==
  == System Overview ==
  Move support can be added in phases.  The “core components”, outlined in yellow in the
following diagrams. must be upgraded to get a basic level of support in which commits and
updates support moves.  The other components, including merge, can be supported later.
  
  Client side:
  
- 
- 
  Server side:
- 
- 
  
  == Core Components ==
  === Client ↔ RA ↔ Repos ===
@@ -89, +81 @@

  
  When not being driven by a move-aware editor:
  
-  * Insert the heuristic move-detector, if 	desired.
+  * Insert the heuristic move-detector, if       desired.
   * Otherwise, only copies and deletes are seen.
-  * Lose any move heuristics currently built in 	to copy & delete. I think this only
affects the conflict 	resolution.
+  * Lose any move heuristics currently built in  to copy & delete. I think this only
affects the conflict        resolution.
  
  === Repos ↔ FS ↔ FSFS ===
  TODO...
@@ -104, +96 @@

  ==== In existing FSFS (format 6) ====
  Alter the node id and copy-id assignment rules.
  
-  * A moved node gets the same copy-id as its 	copy-from node.
+  * A moved node gets the same copy-id as its    copy-from node.
-  * All children of a moved node get the same new 	copy-id as their parent.
+  * All children of a moved node get the same new        copy-id as their parent.
  
  Adjust implementation of existing APIs to see those moves as copies (for back-compat).
  
@@ -117, +109 @@

  ==== New FS APIs ====
  Provide new APIs that see moves as moves:
  
-  * Find “the same” node in another revision. 	This query can be shaped in various ways,
such as:
+  * Find “the same” node in another revision.    This query can be shaped in various
ways, such as:
- 
-   * For a given set of nodes in revision X, find 		where the “same” nodes exist in revision
Y.
+   * For a given set of nodes in revision X, find                where the “same” nodes
exist in revision Y.
-   * Compare directories PATH1@REV2 and 		PATH2@REV2, and return a list of matching name-pairs
between them.
+   * Compare directories PATH1@REV2 and          PATH2@REV2, and return a list of matching
name-pairs between them.
  
  TODO...
  
@@ -130, +121 @@

  === Delta-Editor ===
  Options:
  
-  * Transmit moves transparently over the old 	svn_delta_editor_t.  A move-aware producer
will drive the existing 	editor interface in a way that is (more or less) backward compatible
	with existing consumers.
+  * Transmit moves transparently over the old    svn_delta_editor_t.  A move-aware producer
will drive the existing      editor interface in a way that is (more or less) backward compatible
   with existing consumers.
  
-  * Use Ev2.  Supposed to have support for moves. 	 Untested and unknown.
+  * Use Ev2.  Supposed to have support for moves.         Untested and unknown.
  
  It may be better to start by adding support to a well known editor first, if that is possible
(which it seems to be).  Then see if there are any functionality or efficiency issues that
could be improved by use of Ev2 (or something like it).
  
@@ -184, +175 @@

  == Backward Compatibility ==
  We can and will preserve backward compatibility between move-aware clients and move-unaware
repositories, and between move-aware repositories and move-unaware clients.  There are two
complementary parts to this:
  
-  * when sending a move to an old client or 	server, we shall convert to copy + delete;
+  * when sending a move to an old client or      server, we shall convert to copy + delete;
-  * when receiving copy + delete from an old 	client or server, we could heuristically convert
some cases to a 	move.
+  * when receiving copy + delete from an old     client or server, we could heuristically
convert some cases to a        move.
  
  === Heuristic Detection of Moves ===
  The server could perform heuristic detection of moves when an old client is committing.

Mime
View raw message