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?action=diff&rev1=8&rev2=9 Comment: Add a section on Move Semantics === Repo Format Bump === It is essential that the repository filesystem 'knows' whether move semantics are enabled, because copy-and-delete must then no longer be interpreted heuristically as a move. This could be indicated by bumping the FS format number, if it applies to the whole repository, or potentially we could mark that all revisions after a certain point have move semantics enabled whereas prior revisions don't. + = Move Semantics = + This section specifies the logical semantics of the versioned move operation that is the basis of move tracking, independent of any implementation. + + A versioned move of the node with node-copy-id “N”, with respect to two revisions rX and rY (X < Y), shall mean: + + * '''Same node-copy-id.''' A node with node-copy-id N exists in rX and in rY. It is “the same node”. It therefore has the same node kind. It may have content modifications. + * '''No gap.''' There cannot be a gap in the range of revisions: node-copy-id N exists in every revision rX, rX+1, …, rY-1, rY. + * (Contrast with copy-and-delete, where there can be a gap between the delete and the copy.) + * (The possible “resurrection” extension to these semantics would permit a gap.) + * '''Move and/or rename.''' Node N has either or both of + * a different name (base name) in rX than in rY; and/or + * a different parent (parent directory node-copy-id) in rX than in rY. + * '''Children follow.''' If N is a directory, each child (recursively) of N in rX remains a child of N in rY, with the same name, unless it is separately moved or deleted. Any or all of the children can be separately moved within or outside the subtree at N, at the same time as N is moved. + * '''No null move.''' An attempted move which does not change the node's name or its parent node, with or without a modification, is not distinguished from a normal succession of history. + + === Properties === + In the notation A@X, A represents a parent directory node-copy-id and child name, while X represents a revision number. + + Properties of the move relationship: + + * '''Transitive.''' move(A@X,B@Y) followed by move(B@Y,C@Z) collapses to move(A@X,C@Z). + * '''Reversible.''' move(A@X,B@Y) followed by move(B@Y,A@Z) collapses to no-move. + * '''Time-symmetric.''' move(A@X,B@Y) is symmetric with the time-reversed relationship move(B@Y,A@X). + + === Move versus Rename === + In the versioned data model semantics, “move” refers to a change of parent node and/or a change of name. + + At a higher level of semantics, for example when resolving conflicts during merge, it can be useful to distinguish between renaming and moving to a different parent node. + + === Can't Move a Child of a Copy === + Moving a child of a copy, within the same revision, is not tracked: it is an ''unversioned'' operation. + + A versioned "move" takes a node that existed in the previous revision and places it in a new location. A copy, however, always creates ''new'' nodes, conceptually, even if the internal representation is a "lazy copy" pointer to the old node. Moving a child node therefore is a rearrangement of the new content. It is semantically the same as deleting the child node and creating a copy of it somewhere else. Compare with copying a node and then moving that copy somewhere else. + + If we perform a copy and then move a child of it, either in a WC or in a repository, this should create a copy with a deleted child, and then another copy somewhere else which is the "moved" child in its new location. We can describe the relationship between the initial and final states perfectly well without saying "move", in the form "the subtree at path P@X is copied to path P1@Y, except for its child C which is copied to path P2/C@Y instead". Thus there is no loss of semantic information despite the absence of “move” in the result. + + === Extension: Resurrecting a Deleted Node === + A possible extension to the move semantics would be to allow a previously deleted node to be resurrected at the same location or at a different location. +
