Changes to Core Components
The main functional changes are in the following areas. Many smaller changes will also be needed; for example, to make the log command report moves as such.
APIs, Protocols, Formats:
- delta editor API
- httpv2 protocol
- svnserve protocol
- FS API
- FSFS format
- dump file format
- commit driver (WC)
- update editor (WC)
- commit editor (FSFS)
- repos diff (repos layer)
- FS query functions (FSFS)
- svnadmin dump/load
Major and minor changes essential for Phase 1 are listed in the following subsections.
Delta Editor API
- Add 'move-away' and 'move-here' methods.
- New: svn_fs_move(svn_fs_root_t *root, from_path, to_path)'. Similar to copy and delete, except the copy will keep the same (node-id, copy-id) as its source. 'root' must be the root of a transaction.
- New query API to find the same node-line in another revision: See under “Commit Editor and Query Functions (FSFS)”.
See under “Commit Editor and Query Functions (FSFS)”.
Dump File Format
Commit Driver (WC)
- WC describes each move from the WC DB to the move-aware editor.
Update Editor (WC)
- 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).
Lose any move heuristics currently built in to copy & delete. I think this only affects the conflict resolution.
RA-serf, RA-svn, mod_dav_svn, svnserve
- Use move-aware editor APIs and transmit and receive moves.
- Use move-aware editor APIs.
Repos Diff (repos layer)
- Extend repos diff to calculate and transmit moves, using the new FS query API.
Commit Editor and Query Functions (FSFS)
Changes needed to extend FSFS format 6.
- A lazy child of a copied node always gets a new copy-id, never the copy-id of its parent, when un-lazified.
Or something like that. Brane?
- New FS vtable method 'move(svn_fs_root_t *root, from_path, to_path)'. Similar to copy and delete, except the copy will keep the same (node-id, copy-id) as its source. 'root' must be the root of a transaction.
- New API to find the same node-line in another revision. This query can be shaped in various ways, such as:
- For each of a given set of node-line-ids, find the path where it exists in revision Y.
- For each of a given set of paths in revision X, find the path where the same node-line exists in revision Y.
- Compare directories PATH1@REV2 and PATH2@REV2, and return a list of matching name-pairs between them.
- 'changes' list - record as a 'move'
- Adjust implementation of existing query APIs to report moves as copy-and-delete, for back-compat.
- [minor] 'move URL URL' uses move-aware editor and sends a move.
- svnadmin dump writes moves to dump file
- svnadmin load reads moves from dump file
- upgrade marks the repository as having move semantics enabled (in new revisions)?