> Actually, we don't want 'mv' as a primitive operation; that would
> imply that we don't care one whit about what's being moved.
Thanks for the reply. I hear that you don't want a primitive move
operation, and I seem to detect some back story that's opaque to me.
However, I don't see how you can reconcile the stated goal in "goals"
in the documentation section with the implementation of
"move == delete + add".
> Instead, we have 'mv == delete + add', which has been working very
> well for us. It means that the thing we add is specific. The bug
> here (which Karl just filed today) is that we're not paying attention
> to the thing we delete. We need to notice that we're deleting a very
> specific thing, and warn otherwise.
If you pay attention to "deletion" then you'll get a warning about
someone renaming something that you have changes open in. However, I
believe it would be more useful to just apply the changes to the newly
renamed version of the file. And if you sync a rename while you have a
file open (or have local changes) then that file gets renamed, retaining
your local changes.
I fail to see how that behavior could be anything but Very Desirable.
Please, enlighten me (or point me at some resource where this is
discussed in detail).
Also, if you have to have a two-part implementation, then I would
suggest using copy+delete rather than delete+add, because with copy+
delete the audit/versioning trail is typically much clearer and easier
to follow.
Cheers,
/ h+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 11 00:47:29 2002