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.
