Quoth Kent Tong <>:
> 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.
Being unversioned, it can't maintain any sort of relationship with F2.
If you look at F2's history, though, you'll be able to see where it came
from.
> 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?
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
So, now the user has a (conflicted) modified version of F1 and the
official F2. It should be fairly obvious what happened from the update
messages and log. They then need to transfer across their changes to
F2.
But why does it leave F1 unversioned when they "resolve conflicts"?
Because it's the rules :) When you resolve conflicts, it indicates to
Subversion that you're happy for it to go ahead and do what it normally
would (in this case, delete the file) -- but it's forbidden to delete
modified files ;)
> 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?
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 :)
---------------------------------------------------------------------
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:14:12 2005