Re: Renaming files on win32

Scott Palmer <scott@digital-rapids.com> writes:

> you can't _directly_ rename "Abc" to "abc".
>
> On windows if you have a file "Abc" and you rename it to "abc" in the
> local filesystem it just works. There is no reason to not allow this
> as long as something named "file" does not already exist in the
> working copy which is impossible on Windows anyway. It seems there is
> a bug in Subversion in that it tries to access "abc" -- which on
> windows successfully accesses "Abc", and then Subversion gets confused
> about the existence of the target name, when it fact it is detecting a
> bogus conflict with the source name.
>
> Surely THAT can be easily fixed?

If you are talking about a wc-to-wc copy then no, it's hard. At
present mv is implemented as copy+delete. That means that until the
delete is committed the working copy has to maintain files associated
with both "Abc" and "abc".

$ ls wc
foo
$ svn mv wc/foo wc/FOO
A wc/FOO
D wc/foo
$ ls wc
FOO
$ ls wc/.svn/text-base/
FOO.svn-base foo.svn-base

See, both foo and FOO. NTFS in case-insensitive mode doesn't appear
to support that (although if it were switched into case-sensitive mode
I guess it might work). In the past I have considered two changes
that might fix this:

- have schedule delete items moved into a .svn/deleted/ directory
- implement atomic move in the working copy

but neither of these is easy.

If you are talking about an URL-to-URL copy, the problem is that the
add arrives before the delete

$ svn up wc
A wc/FOO
D wc/foo

so before the delete arrives there are again two sets of files in the
working copy. It might be possible to solve this by reversing the
order in which the add and delete arrive, but I've never tried that.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org