> -----Original Message-----
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: woensdag 7 december 2011 13:13
> To: dev@subversion.apache.org
> Subject: Move tracking and NODES.moved_to/moved_here
>
> 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.
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.
> 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?
> 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?
There has been some discussion, and I think stsp should have some pointers.
There was some discussion on dev@ before the data was moved to BASE and
before that a discussion on IRC.
Bert
