"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
http://www.uberSVN.com
Received on 2011-12-07 14:18:44 CET