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

Re: Move tracking and NODES.moved_to/moved_here

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Wed, 07 Dec 2011 13:18:06 +0000

"Bert Huijben" <bert_at_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_at_N)
   D Xcopy/Y
   A Ycopy (from X/Y_at_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
Received on 2011-12-07 14:18:44 CET

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