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
> TODO
>
> 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?
Cheers,
--
Johan
Received on 2011-04-12 23:15:20 CEST