bzr move in widows: directories are case sensitive

It's actually intended behavior. Otherwise you can't rename (change only the case) directory:

bzr init
bzr mkdir foo
bzr mv foo Foo

Per example svn refuse to rename (change only case) in this situation, and I think it's wrong behavior.

So actually we have dilemma here: allow change case of files/directories, and accept name aliases on case-insensitive filesystem. I prefer first variant because I want to change case time to time.

So I'm inclined to mark this bug as Won't Fix. Sorry.

In most cases bzr can distinguish case change from move into directory named in different case

anyway this should work:
bzt init
bzr mkdir A
bzr mkdir b
//create file.txt in A
bzr move a/file.txt b/
bzr: ERROR: Could not move file.txt => b: a/file.txt is not versioned.
W:\test\case>bzr mv A/file.txt B/
bzr: ERROR: Could not move to B: B is not versioned.

in both case the behavior seems unambiguous (first param file, second - dir)
and it does not disable the ability to change case of files/dirs

OK, I get the point. It seems bzr could handle this situation more gracefully.

Another facet of the same problem, which I think is more serious:

c:\temp\BzrBug>mkdir Branch1
c:\temp\BzrBug>mkdir Branch2
c:\temp\BzrBug>cd Branch1
c:\temp\BzrBug\Branch1>bzr init
c:\temp\BzrBug\Branch1>mkdir TEST
c:\temp\BzrBug\Branch1>cd TEST
c:\temp\BzrBug\Branch1\TEST>echo foo > foo
c:\temp\BzrBug\Branch1\TEST>bzr add foo
added TEST
added TEST/foo

c:\temp\BzrBug\Branch1\TEST>echo bar > bar
c:\temp\BzrBug\Branch1\TEST>cd..
c:\temp\BzrBug\Branch1>bzr add test\bar
added test
added test/bar

c:\temp\BzrBug\Branch1>bzr status
added:
  TEST/
  TEST/foo
unknown:
  TEST/bar

#### Above is the first sign that something is wrong.

c:\temp\BzrBug\Branch1>bzr commit
Committing to: C:/temp/BzrBug/Branch1/
added TEST
added test
added TEST/foo
added test/bar
Committed revision 1.

#### Notice that both TEST/foo and test/bar are added. However the real problem happens when you try to pull:

c:\temp\BzrBug\Branch1>cd..
c:\temp\BzrBug>cd Branch2

c:\temp\BzrBug\Branch2>bzr init
c:\temp\BzrBug\Branch2>bzr pull ..\Branch1
+N TEST/
+N TEST/foo
+N test.moved/
+N test.moved/bar
Conflict adding file TEST. Moved existing file to test.moved.
1 conflicts encountered.
Now on revision 1.

#### Changes from Branch1 cannot be properly pulled to Branch2 because bzr renames the directory during the pull.

This is a problem for me right now since I added many files with the wrong case a few days ago and now cannot pull my changes from my desktop to my laptop. A fix (or even just a workaround) would be greatly appreciated.

Thanks!

>It's actually intended behavior. Otherwise you can't rename (change only the case) directory:
>
>bzr init
>bzr mkdir foo
>bzr mv foo Foo

Couldn't you handle both cases by checking the underlying file system and seeing if it support case sensitivity? If not, then the command does nothing. (You could return an error). Otherwise, the command continues as you intend. On the flip side:

>mkdir b
>bzr mv A/file B/file

a check for case-sensitivity of the file system in this case would allow the command to complete appropriately, but only if the file system was NOT case sensitive.

You can in theory use os.path.normcase to detect a case-insensitive filesystem (Windows, MacOS HFS+, Cygwin, OpenVMS). However IIRC that always returns a lowercase filename (uppercase on VMS if Python even runs on that platform) so to support most operations we also need to do a case-insensitive path2id call. That has the potential to get ugly pretty quickly performance-wise, I think; but it might be worth the tradeoff to get better behaviour.

John C Barstow пишет:
> You can in theory use os.path.normcase to detect a case-insensitive
> filesystem (Windows, MacOS HFS+, Cygwin, OpenVMS). However IIRC that
> always returns a lowercase filename (uppercase on VMS if Python even
> runs on that platform) so to support most operations we also need to do
> a case-insensitive path2id call. That has the potential to get ugly
> pretty quickly performance-wise, I think; but it might be worth the
> tradeoff to get better behaviour.
>
WorkingTree is already has check to detect case-insensitive
filesystem. But this info is not used very often inside bzrlib.

--
All the dude wanted was his rug back