|Deletions are marked like this.||Additions are marked like this.|
|Line 36:||Line 36:|
|=== FS API ===
These new APIs are required:
1. A way to find what has moved between two repository trees. (In the repos layer, responding to the "report", this needs to be a comparison between a mixed-revision state and a single-revision tree.)
1. A way to record moves during a commit.
==== 1. Query ====
New query API to find the same node-line in another revision: See under “Commit Editor and Query Functions (FSFS)”.
The form of the query API could vary from the small scale such as querying the path at which a given node-line-id lives in a particular revision, to the large scale such as asking for all the moves between a given pair of revisions across the whole versioned tree. The form suggested here is at an intermediate level: children of a directory.
* Given two versioned directories, DIR1@REV1 and DIR2@REV2 (REV1 != REV2), return a list of (NAME1, NODE-LINE-ID, NAME2) tuples containing each node that is an immediate child of DIR1@REV1 and/or of DIR2@REV2 and is moved in REV2 relative to REV1. In a given entry, NAME1 or NAME2 is null if the node moved into DIR2 or out of DIR1 respectively.
That form reports renames directly and enables the caller to build up a mapping of cross-directory moves by combining the results of multiple queries.
Since that form only looks at a directory's children, we will also need a single-node query. It could be in this form:
* Given an existing node PATH1@REV1 and an existing revision REV2, return PATH2 at which the same node-line lives in REV2, or null if it does not.
==== 2. Commit ====
The following new method is needed:
* 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.
=== FSFS Format ===
See under “Commit Editor and Query Functions (FSFS)”.
|=== FS API, FSFS, FSFS Format ===
|Line 83:||Line 58:|
|=== FSFS ===
Changes needed to extend FSFS format 6 (or 7?).
* A lazy child of a copied node always gets a new copy-id, never the copy-id of its parent, when un-lazified.
* ''Is'''' that ''''correct,'''' ''''Brane?''
* New FS vtable methods to implement the interfaces defined in the 'FS' section.
* 'changes' list - record as a 'move'
* Adjust implementation of existing query APIs to report moves as copy-and-delete, for back-compat.
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.
FS API, FSFS, FSFS Format
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.
- [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)?