How do I resolve this case-sensitivity problem on Windows.

[Talden]

>  > NB: I know the ideal is to use "bzr mv" instead of the rename - this
>  > is a contrived example to simulate something that happened with a new
>  > vendor drop amongst thousands of files.
>
>  Yes, using mv is the right way for now.

Unfortunately that's not useful in this case.  Because until you do
the drop (replacing a number of files, removing some and adding new
ones) of the new vendor release you don't realise this is going to
happen - by which stage your working tree is broken.

This seems to be a working solution... maybe there are unnecessary
steps - perhaps the 'Third' commit can be avoided if someone knows
whether the book-keeping can be tricked into the right state.

if exist MixedCaseWedgedWorkingTree rmdir /s/q MixedCaseWedgedWorkingTree
md MixedCaseWedgedWorkingTree
cd MixedCaseWedgedWorkingTree
bzr init

rem Create the file and commit it
echo Foo > Foo.txt
bzr add
bzr commit -m "First"
dir
bzr st

rem OS rename the file and commit.
rem Note the dirty status.
ren Foo.txt foo.txt
bzr add
bzr commit -m "Second"
dir
bzr st

rem Do a revert to get a commit without either version of file
rem All clean
bzr revert -r1 foo.txt
bzr commit -m "Third"
dir
bzr st

rem Pull out the file from history and bzr move it to the new name
rem All clean (well apart from the surreal history)
bzr revert -r1 Foo.txt
bzr mv Foo.txt foo.txt
bzr commit -m "Fourth"
dir
bzr st

--
Talden