This is about tracking local, uncommitted moves in thw working copy. Trunk has begun to use the NODES columns moved_to and moved_here that are unused in 1.7. I'm a bit confused about how it is supposed to work.
moved_to is a relpath while moved_here is treated as a boolean, with repos_path providing "moved_from". The current trunk behaviour is that moving X to Y sets moved_to on the base node of X, and moved_here on the working node of Y. A subsequent move of Y will cause moved_to on X to be updated with the new location. So move tracking doesn't record every individual move but some superposition of all the moves. 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. 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. So where should we record moved_to? There seem to be two options: either in the working base-deleted node or in the base/working normal node below the working base-deleted node. Has ther been any earlier discussion of this design? -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com