Gavin Lambert <gavinl <at> compacsort.com> writes:
> Subversion supports local renames. However they're propagated to the
> repository as a "delete + add with history", meaning that clients other
> than the one that issued the "svn mv" command are not aware that F1 was
> renamed. What happens on the remote end is this:
> - remote client receives "F1 was deleted"
> - if local copy of F1 has not been modified, then local F1 is
> deleted. No problem.
> - if local copy of F1 has been modified, then we can't delete it;
> flag conflict and leave it alone.
> - remote client receives "F2 was created with this history"
> - create new file F2
Thanks for the info on its true behavior.
> More confusing than dangerous, I think. After all, they'll get the
> extra file shoved in their face by svn status (and regular directory
> listings) until they do something about it :)
It is quite common for a programmer to create over a dozen new
files before he tries to commit. Usually one would just select
to add the unversioned files to the repository. So it's impractical
to ask him to check.
A workaround is to ask people to get alerted when they see a conflict
and the remote file is empty (in subclipse). Then they should really
check if it's a delete or a move.
Given this confusing/dangerous behavior, do the developers of subversion
plan to support a genuine move operation in the future?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 5 07:56:22 2005