Re: Renaming only case on Windows

At 2:40 AM +0200 8/31/03, Daniel Schlyder wrote:
> >>$ svn mv file:///repos/trunk/foo file:///repos/trunk/Foo -m "Renamed file."
> >>$ svn up
>
> > Here, "rm foo" between the svn commands would have made it all work. Or, in
> > general, when you see "obstructed update," you can respond by removing or
> > renaming the obstructing file. This is another case of SVN's care not to
>> trash anything of yours.
>
>I couldn't get this to work. 'svn up' fails with error:
>
>Restored foo
>svn: Obstructed update
>svn: failed to add file 'Foo': object of the same name already exists

Whoah, you're right! More specifically: when you update the rename
of Foo to foo (after moving the obstructing old "Foo" aside), the
update of the new, desired file ("foo") works, but then you get an
"Obstructed update" complaint about the old, defunct spelling
("Foo"). [Note that I think the original svn commands at the top,
and the svn messages at the bottom, are for reversed cases here,
right?]

I daresay what's "obstructed" is the removal of the old spelling (on
the positive side, it's good that SVN *did* notice that the new
spelling was in place, and not simply remove it while trying to
remove the old one!).

At the moment, I think they only way to get there from here is this sequence:

> >>$ svn mv file:///repos/trunk/foo file:///repos/trunk/Foo.tmp -m
>"Renamed file 'foo' to 'Foo.tmp'."
> >>$ svn up
> >>$ svn mv file:///repos/trunk/Foo.tmp file:///repos/trunk/Foo -m
>"Renamed file 'Foo.tmp' to 'Foo'."
> >>$ svn up

Here, the deletion of the old spelling happens during the first 'svn
up', and there's no obstruction in renaming back to the new spelling
during the second 'svn up'. There is, of course, and extra revision
in this solution (which you elsewhere mentioned wanting to avoid).
And every other working copy (on a case-challenged system) is going
to have to do two updates to cross this boundary as well, either in
synchrony with this process ("svn mv; OK, everybody update; svn mv;
OK, everybody update again"), or by explicitly naming the middle
revision. Yuck.

I think this amounts to another case of issue 898
<http://subversion.tigris.org/issues/show_bug.cgi?id=898>
variously called "rename should be atomic" and "rename should not be
implemented as 'copy + delete.'"

-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org