A specification for changes needed in FSFS and the FS API in order to support moves.

See also the specification of the semantics of moves: MoveDev/MoveDev#Move_Semantics.


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.)
  2. 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.

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:

2. Commit

The following new method is needed:


Changes needed to extend FSFS format 6 (or 7?).

Flag Move-Aware Semantics

Consider whether we need to identify move-aware revisions as such. This might be a single flag for the whole repository (perhaps a format upgrade), or a cut-off revision after which all further revisions are move-aware, or a flag per revision identifying whether a move-aware client made the commit.

The purpose of this information would be to be able to know explicitly that copy + delete does not mean 'move' in those commits. Is this distinction necessary? How would the information be used? (Client side? Server side?) What are the pros and cons?