Re: Move tracking and NODES.moved_to/moved_here

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?

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

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.

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

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com