Philip wrote: > "Bert Huijben" <b...@qqmail.nl> writes: >>> That's relatively simple but it raises one big question: is the base >>> node the right place to record moved_to? What about nodes without base >>> nodes? When X is the child of a copied directory that is not a >>> replacement then X will not have a base node, but if the copied >>> directory is a replacement then there may be a base node for X, although >>> it is not really connected to X. >> >> We used to store it in op_depth > 0 before, in the same record as >> base-deleted (or other states) but that was hard to track in the scan >> functions and it took a lot of effort to keep these nodes in sync. (stsp >> knows the whole story) >> >> You can't really move WORKING (op_depth > 0) nodes as that would be a 'local >> only' change. Per definition that wouldn't be a repository recordable-move. >> The only case where you would want to track those moves, is when they are >> also stored in a different place in BASE. > > This is about recording local moves, not repository moves. > >>> So inside a replace we sometimes record moves and at other times we do >>> not. That doesn't seem right, but the solution is not as simple as >>> saying "never record inside a copy" because I think we do want to record >>> such moves: merge may want the information, commit certainly wants it to >>> prevent partial commits. >> >> I don't know how you want to record in the repository that a node is new >> (added) and moved to a different place in a single revision? > > Suppose I move something from inside a copy to outside the copy. On > commit we get:
Is there a bit of terminology mix-up here between "add" and "copy"? I think it would help clarity if we took a lead from Greg in reserving the word "add" for creation of a new item with no history, and otherwise saying "copy" or "move" as appropriate. > A Xcopy (from X@N) > D Xcopy/Y > A Ycopy (from X/Y@N) > > If we don't track that move then the user will be able to commit just > half of it. Are we going to say that's not a move? That it is sensible > to commit only one half of the move? > > Or suppose I merge a revision that adds X containing X/Y, then I merge > (with a new merge-aware merge) another revision that moves X/Y to X/Z, > then I merge another revision that modifies X/Z. The second merge, the > one that moves X/Y to X/Z may not even be a merge, it may be conflict > resolution. The final merge needs to know that locally added X/Y has > been moved to X/Z. (In this example, X is created in the WC as a "copy". Merge currently never performs an add in the "new creation" sense; an add in the merge source becomes a copy in the merge target.) - Julian
