How do I resolve this case-sensitivity problem on Windows.
Talden
talden at gmail.com
Wed Mar 5 10:49:45 GMT 2008
> > 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
More information about the bazaar
mailing list