Saulius Grazulis <grazulis <at> akl.lt> writes:
> To my taste, this looks as completely expected and normal behavior. Since user
> 1 renamed F1, thus effectively removing it from version control, any file
> named F1 from that point on becomes unversioned.
As it is a move operation, people should expect that F1 becomes F2. That
is, F2 is the next version of F1. The local F1 should not become unversioned
and should not become completely unrelated to F2.
> Since user 2 had local changes to the file F1, the file is not removed but
> left alone. Since user 2 accepted deletion of file F1 by saying "resolved",
> the file becomes unversioned. User 2 is now free to do whatever he/she wants
> with file F1 -- add and commit, remove, copy to a safe location, etc.
This breaks the relationship between F1 and F2. One of the selling point of
subversion over CVS is that it allows file renames. But if the relationship
between F1 and F2 is not maintained, then how can such claim be substantiated?
> > This is a very dangerous behavior.
>
> What is so dangerous about it? If I understand you correctly, no information
> was lost. The file F1 was left in user's 2 directory, with all local changes
Say the team has been using a file UrlUtil.java. But they find that it should
be named to URLUtil.java. So one team member renames it. When another team
members performs an update, if he has made changes to UrlUtil.java, he will
get both UrlUtil.java and URLUtil.java. Later some members may make changes
to and/or use UrlUtil.java while some other may make changes to and/or use
URLUtil.java. Isn't this dangerous?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 5 04:22:24 2005