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