[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: weird behavior with simultaneous edit and move

From: Kent Tong <kent_at_cpttm.org.mo>
Date: 2005-12-05 07:52:09 CET

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

This is an archived mail posted to the Subversion Users mailing list.