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
Received on 2011-12-07 15:36:35 CET