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/MoveDev" by JulianFoad
Date Thu, 13 Jun 2013 14:15:28 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

New page:
= How to Add Moves to Svn =
(A System Overview)

Move support can be added in phases.  The “core components” must be upgraded to get a
basic level of support in which commits and updates support moves, and the infrastructure
required.  The “optional components” can be supported later, and include merge.

Core components:

 * WC up/sw editor
 * Client/WC commit edit-driver
 * RA diff/up/sw/st edit-driver
 * RA commit editor
 * RA-serf protocol; RA-svn protocol; RA-local  interface
 * Repos API
 * FS API
 * FSFS

Optional components:

 * Client-lib diff (plain text; git format;     summary)
 * Client-lib merge
 * Client-lib status
 * Client-lib: repos-repos diff
 * WC-lib: repos-wc diff

== Core Components ==
=== Client ↔ RA ↔ Repos ===
The only Client → Repos op affected is Commit.  (There are also simple commit actions, of
which 'move URL URL' is probably the only relevant one.)  Commit will use a move-aware delta-editor.
 We already have local moves in the WC, so we just need to describe those to the editor as
moves.

The Repos → Client ops affected are Diff, Update, Switch, Status.  These all work in a very
similar way.  Each one sends a Report and receives a delta-edit.  They will use a move-aware
delta-editor.

==== Commit ====
WC descibes each move from the WC DB to the move-aware editor.

When not using a move-aware editor, WC describes each move from the WC DB as copy & delete
in the old way.

==== Update/Switch/Status/Diff ====
WC receives each move from the move-aware editor.

WC performs the move.  (non trivial)

Moves do not conflict with edits (of a file and/or of a tree).

When not being driven by a move-aware editor:

 * 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.

=== Repos ↔ FS ↔ FSFS ===
TODO...

=== Within FSFS ===
Introduce 'move' as a new, distinct operation.  Add move-tracking APIs.

==== 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.
 * 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).

Add new APIs as detailed below.

==== In a new FSFS ====
Move will be a first-class operation.

==== 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:
  * 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.

TODO...

=== Reporter ===
Needs no changes.  (The reporter does not report changes, it just reports a base state.)

=== Delta-Editor ===
Moves will be transmitted 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.

 * What about Ev2?  Supposed to have support for        moves.  Untested and unknown.  Seems
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).

==== Adding a 'move' operation (and negotiate the use of it) ====
Introduce a 'move' method in the vtable.

Feature negotiation (when driving or receiving an edit over the network to a potentially older
client or server), for

 * whether the 'move' operation is allowed

(We cannot just assume copy & delete means move because, when a move-aware subsytem sends
or receives copy & delete, it does __not__ mean move.)

==== Entry-props method (backward-compatible) ====
Augment the existing 'delete' and 'copy' ops with move info that is ignored by old consumers.
 Src path and Dst path of a move are transmitted in entry-props before (or during) the Del
and Add.

A move-aware consumer will process a pair of 'add' and 'delete' ops as a move if the additional
move info is present, or in the old way if not.  Thus the scheme is backward compatible in
both directions.

The entry-props can be attached to any convenient path.  A convenient choice is the parent
dirs of the two operative paths.

==== Copy-from-rev = -1 method (not compatible) ====
We can define a particular consumer will perform a move when it receives

Add(copy-from-path = X, copy-from-rev = -1)

which means “move from X to here”.

The consumer has to handle the Del in such a way that it can later be converted to a move
if and when a move arrives.

This is not backward-compatible with existing editor transports nor with existing consumers.
 Consumers obviously would fail, and editor transports often assert that the copy-from-rev
is valid when copy-from-path is valid.

This method can be used where back-compat is not needed, such as in the RA-local interfaces,
if it has any benefit over the entry-props method.

==== Both methods: careful with the paths ====
Define the frame of reference for the paths carefully.  In a nested move, the delta editor
will see the 'move from' path in one frame of reference during the Del operation, and in another
frame of reference during the Add op.

In a sane editor drive [1], once a path has been added it is not subsequently moved, so any
Add path corresponds directly to a path in the final state of the tree.  However, after a
Del (mv-away), any of the implicitly deleted children of that subtree may subsequently be
the source of a move.

Mime
View raw message