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
Received on 2011-12-07 13:13:18 CET