[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Case-only renames on Windows (issue #3702)

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 12 Apr 2011 23:14:28 +0200

On Fri, Mar 25, 2011 at 2:21 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Sun, Mar 20, 2011 at 9:32 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> Some thoughts:
>> - There is only a problem if the dst_path gets case-normalized to one
>> of the source paths. Otherwise, the case-normalization really does
>> need to happen.
> Hm, this thought may be incorrect (or at least "unexpected" for
> windows users). In fact, if we look at how the native "move" behaves,
> it never case-normalizes the target path:
> [[[
> C:\Temp>dir /B test
> C:\Temp>echo anothertest > bla
> C:\Temp>move bla test\toDO
> Overwrite C:\Temp\test\toDO? (Yes/No/All): y
>        1 file(s) moved.
> C:\Temp>dir /B test
> toDO
> C:\Temp>type test\todo
> anothertest
> ]]]
> So it seems that, if we want "svn mv" to behave more like "move" on
> Windows, the target path should never be normalized to the on-disk
> casing. Just use it as is ...

Finally getting around to this again ... the above is still an open
question for specifying the desired behavior of "svn move" on Win32
... If there is a file A on disk, what should "svn move B a" do?

In theory it could generate a replace of A by a ("copied from" B).
That would be consistent with behavior of Windows' "move" command,
after confirming the overwrite.

But, lacking the "confirm-for-overwrite", I guess the behavior most
consistent with existing svn functionality would be to refuse this
move in the same way as "svn move B A" is refused. Currently, this is
with the (slightly not-to-the-point) error message: "svn: E155007:
Path 'C:\temp\bla\A' is not a directory".

Would that be ok?


Received on 2011-04-12 23:15:20 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.