You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by Apache subversion Wiki <co...@subversion.apache.org> on 2013/05/30 15:33:19 UTC
[Subversion Wiki] Update of "MoveDev/MovesOverDeltaEditor" by JulianFoad
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "MoveDev/MovesOverDeltaEditor" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/MoveDev/MovesOverDeltaEditor
New page:
Here is a method to communicate moves over an ''svn_delta_editor_t'' edit drive.
It requires modifying the sender and the receiver but uses the existing editor protocol. It requires a small amount of extra communication -- the list of moves -- which may be communicated out of band or carried inside the edit drive (for example, as properties that the consumer recognizes as special).
The aim is for a move-aware producer to be able to drive a move-unaware consumer and ''vice-versa''.
It assumes:
* A depth-first tree walk.
* Nodes identified by path alone (no node ids).
* The only tree-change operations are:
* add node
* copy subtree (from ... [1])
* delete subtree.
* A way to communicate the moves.
* No additional ordering requirements.
This method can probably be adapted to other editors such as ''svn_wc_diff_callbacks_t''.
== Basic Method ==
* Producer sends the "from" and "to" paths of each move, before or during the corresponding "delete" and "copy" operations.
* When the consumer sees a "delete" that corresponds to a move:
* It does not perform a delete.
* If necessary (to allow a subsequent replacement), it moves the path to a temporary location and keeps track of it.
* When the consumer sees a "copy" that corresponds to a move:
* It performs a move from the "move-from" path.
* It applies any modifications.
== Example ==
Starting from:
{{{
/
+-- A/
+--foo
}}}
Rename 'A' to 'B':
{{{
/
+-- B/
+-- foo
}}}
Where the copy and the delete are in the same directory, so our present edit producers send the 'del' before the 'copy'.
Old sequence (assuming del before cp):
* del A
* cp B from A@10
* modify-props B
* ?? cp B/foo from A/foo@10
New sequence (assuming del before cp):
* moves = [ A -> B ]
* Tells us just the move-root path-pairs
* del A
* Move 'A' to a temporary location (in case a replacement arrives)
* cp B from A@10
* Move temp-A to B. Assert cp-from matches.
* modify-props B
* ?? cp B/foo from A/foo@10
* Is it a move-root? No.
* Is it a move-child? Yes. Assert cp-from matches.