[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Move tracking and NODES.moved_to/moved_here

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Wed, 07 Dec 2011 12:12:37 +0000

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.