"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: 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. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
