"Sindbad the Seafarer" <sindbad.the.seafarer@gmx.net> writes:
> The curious thing, however, is that a search showed wc1/file1 was
> still present,
Yes, this is one of those "tree conflict" situations, specifically
issue 1196 (which Sander is working on right now!)
The situation is: you have a file that is locally modified, and 'svn
up' tries do delete it. This is exactly what happened to you.
At the moment, what happens is that your working file simply becomes
unversioned. It's still present, however. So please don't say any
data was lost... it wasn't. :-)
We're well aware that there are better ways to handle this. The ideal
way is to do what you were hoping: that your locally modified file
would actually get renamed. But in svn 1.0, 'svn mv' really just 'svn
cp + svn rm'. So until we get "true" atomic rename operations in svn
post-1.0, we can't do the ideal thing.
For issue 1196, Sander's going to change the behavior of 'svn up'.
Whenever it tries to delete something that's locally modified, it will
instead error with an 'obstructed update' error. This parallels
existing behavior: an unversioned file can obstruct an addition, and a
modified file can obstruct a deletion. When these things happen, the
user manually moves the obstructing file out of the way, and runs 'svn
up' again to continue. This is better than the status quo, where the
user *may not realize* that the modified file became unversioned.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Sep 7 22:12:00 2003