[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: Julian Foad <julianfoad_at_btopenworld.com>
Date: Wed, 7 Dec 2011 13:58:40 +0000 (GMT)

Philip wrote:
> "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:

Is there a bit of terminology mix-up here between "add" and "copy"?

I think it would help clarity if we took a lead from Greg in reserving the word "add" for creation of a new item with no history, and otherwise saying "copy" or "move" as appropriate.

>   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.

(In this example, X is created in the WC as a "copy".  Merge currently never performs an add in the "new creation" sense; an add in the merge source becomes a copy in the merge target.)

- Julian
Received on 2011-12-07 14:59:17 CET

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