This has been fixed in main, some time before changeset f67d1468ac50.

Specifically, this is probably resolved by change 9865e15febd0.

Fix posted to mercurial-devel as part of the patch series at
http://www.selenic.com/pipermail/mercurial-devel/2008-April/006078.html

See also:
Issue910 ("hg rename -A on Windows deletes file if only case changed")
Issue912 ("hg update fails on Windows if case of file changed in repo")

>3- {a.c} renamed into {A.c}:
>?
>- Cannot be done with windows shell (source and target are the same)

It can be done by command line:

C:\test>dir /b
a.c

C:\test>ren a.c A.c

C:\test>dir /b
A.c

about msg3570:
>3- {a.c} renamed into {A.c}:
>?
>- Cannot be done with windows shell (source and target are the same)

i do such renaming under windows in 2step - 
1st rename {a.c} to something completely another (for example {_a.c}), 
2nd rename this new {_a.c} to required {A.c}

mpm, pmezard: what's the latest status on integrating Andrei's patch (referenced
in msg3563)?

I got it too as case TEST-2 but through hg commit --addremove on a big source
code tree... How can be fixed in dirstate?

I am trying to figure what a case-collision means, when it can happen, and when
we can prevent it. The following tries to summarize what I understand about this
issue. Maybe I am completely wrong or these things were decided a long time ago,
do not hesitate to stop me and enlighten me about it (and tell me exactly what
should be done).

Here are some cases tested on macosx with case-insensitive filesystem with
random remarks:

TESTS
-----
1- {a.c} add {A.c}:
- Add and commit succeed. Next update -C aborts on case-collision.
- Could be fixed in dirstate.

2- {d/d/d/a.c} add {d/D/d/b.c}:
- Add succeeds, but there is a ghost "d/d/d/b.c" shown by status. Nobody
complains ever after.
- Could be fixed in dirstate.

3- {a.c} renamed into {A.c}:
?
- Cannot be done with windows shell (source and target are the same)
- Can be done under macosx
- Without --force, currently aborts cleanly
- Currently buggy with --force because it unlinks target file before copying
- Hard to implement in dirstate because rename = copy + remove in this order

4- {d/d/d/a.c} renamed into {d/D/d/b.c}:
- Currently weird, the move is successful but hg status says something like:
A 	    d/D/d/b.c
R	    d/d/d/a.c
?	    d/d/d/b.c
- Is it legitimate ? After the move, only one directory remains, there is no
in-revision collision. If not, hard to implement given copy + remove order.

5- {d/d/d/a.c, d/d/d/b.c} renamed into {d/D/d/c.c, d/d/d/b.c}:
- Currently weird, the move is successful but hg status says something like:
A 	    d/D/d/c.c
R	    d/d/d/a.c
?	    d/d/d/c.c
- Is it legitimate ? Probably not, we have directory case collision, which goes
undetected on next update -C.
- What if I decide to move files one by one ? I would probably expect the
warnings/aborts to arrive at commit time.

6- {a.c} merge with {A.c}:
- Nobody complains until the next update -C aborts with case-collision.
- Manifest contains both entries while a single file exists
- This goes undetected even with patched dirstate.py detecting case-collisions,
because files are updated in dirstate as normal() by merge.recordupdates()
- I am still not sure which stage is the correct one to detect it and stop the
merge process.

7- {d/d/d/a.c} merged with {d/D/d/b.c}:
- Nobody complains, ever.
- Still the weird ghost entry d/d/d/b.c after the merge.

NOTES
-----
1- We want to detect case-collisions and abort on system where they can occur.
We currently fails to do that for directory case-collisions.
2- We want *at least* the ability to prevent the creation of revisions
containing two manifest entries for the same file. 
a) It looks like a repository property, it does not depends on being on a
case-sensitive filesystem or not. Still, such revisions being created on a
case-insensitive filesystem looks like an error.
b) I am not sure we want to enforce this everytime rules are broken, we may
prefer to enforce at commit time (see case TESTS-4 and TESTS-5).
c) If these checks are implemented in dirstate, it means that a commit always
requires a valid dirstate (maybe that's already true, I am not sure, but I have
seen some "rawcommit" stuff, and I wonder what this implies at API and not ui
level).
d) Even with a patched dirstate.py detecting file and directories collisions
upon add() calls, there are cases (TESTS-6 at least) which goes unnoticed. Does
it mean that files coming from an unrelated repo should be marked "added"
instead of "normal" ? Or the dirstate approach is flawed ? (or my code is broken)

TODO
----
What should be done in which order ?
1- Fix NOTES-1 ?
2- Clarify when we want to warn or abort in NOTES-2.

Having the warnings on all platforms is ok for me.
I haven't looked on the patch though.

I am ready to push a cleaned up version of Andrei's patch
(http://www.selenic.com/pipermail/mercurial-devel/2007-June/002088.html) with a
test. Is anybody OK with the case-folding warnings being issued on all platforms?

Looking at integrating Andrei's patch.

Also issue459

See msg3007