Re: Move tracking and NODES.moved_to/moved_here

Philip Martin wrote:
> Julian Foad <julianfoad_at_btopenworld.com> writes:
>> Is there a bit of terminology mix-up here between "add" and "copy"?
>
> I don't think so?

OK.  I was a bit confused after Bert said "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?" and you responded with talking about a copy that is moved.  But the main issue is that the repository is irrelevant to this thread, so never mind me.

>> 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?
>
> Xcopy is created in the WC as a copy, an add with history.  Xcopy
> contains Xcopy/Y.  Then Xcopy/Y gets moved to Ycopy.  Is that a move
> that should be recorded in the WC?  Do we want it to be possible to
> commit half of the move?

I'm with you on this: yes it should be recorded in the WC and no not half-committable.

> Whether we eventually store it in the
> repository is a separate question, at the moment I'm just interested in
> whether we store it in the WC.
>
>>> 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.)
>
> Yes. X is a copy, and add with history.  X contains X/Y.  X/Y gets moved
> to X/Z (either by a move-aware merge or by a manual move).

I'm with you in principle on what you're trying to say here, I think: if and when we have the ability to interpret incoming 'moves' in this way, then the second merge should be recording in the WC that X/Y has been locally moved to X/Z.

However, I first read your example as meaning there are three successive sync merges from the same source, and in that case the third merge wouldn't need to know about the move because the incoming change would already be talking about path X/Z.

The example works better if the second step is a manual conflict resolution and the third step is a merge where the incoming change is an edit to path X/Y.

> Now consider a further merge, it will produce a tree conflict it it
> attempts to modify X/Y, the modifications should go into X/Z.  If we
> record the Y->Z move then merge can avoid the tree conflict.

Precisely -- agreed.

> (If the Y->Z move was the result of a merge by a move-aware merge then
> explict storage of the move may not be needed, storage of the merge may
> be enough.  But the move may have been a user operation.)

Sounds a bit like what I was saying.

- Julian
Received on 2011-12-07 16:08:19 CET