Resolving Mercurial Case-Folding Collision in Windows

Question

I've seen the other Mercurial case-folding Answers on StackOverflow - they say that if you have access to a case sensitive file system like unix then check out there and it should fix it. Problem is, I don't have access to a unix box, I'm a windows developer developing a windows application.

How do I fix this without a Unix box?

Solution 1

There is a filesystem help topic being worked on that will be included in the next version of Mercurial:

https://www.mercurial-scm.org/pipermail/mercurial-devel/2012-April/039522.html

Renaming colliding files

On case-insensitive filesystems, updating to revisions which have files with case collisions will abort, even with --check or --clean.

To repair such revisions, you should give new names to one or both of the colliding files on a case-sensitive filesystem, and commit them to create new collision safe revision.

.. note:: If you want to (or need to) browse or repair such revisions on case-insensitive filesystems, please see 'Updating manually' section.

If :hg:merge is aborted, but :hg:update --check to each revisions successes, collision occurs between revision to be merged.

In this case, files in one of them or both should be renamed to avoid collision before merging.

With recent Mercurial, you can change case of filename safely in steps below, even on case-insensitive filesystems::

$ hg rename a.txt tmp
$ hg rename tmp A.TXT

Updating manually

If you want to (or need to) update working directory by the revision causing case-folding collision on case-insensitive filesystems, to rename colliding files or browsing contents at such revision for example, please see the Wiki page below::

https://www.mercurial-scm.org/wiki/ManualCheckout

This is NOT recommended for non expert Mercurial users.

Another similar manual method is described here:

https://www.mercurial-scm.org/wiki/FixingCaseCollisions

This also dives rather deep into Mercurial internals though, so you should avoid it unless as a last resort.

Solution 2

We resolved this without resorting to a case-sensitive filesystem by issuing HG rename commands. Say you are having trouble because "Foo.txt" needs to be called "foo.txt":

hg rename Foo.txt Foo.txt.renamed
hg rename Foo.txt.renamed foo.txt

We encountered this problem when a file was deleted and then later re-created in the main repository with the same name, but different case. A branch repository that was created before these changes could not then be merged in, despite the changesets from the main repository having been pulled.

Solution 3

Its a regular problem in Windows for not using case-sensitive file systems. If you want to do it with the TortoiseHg Workbench installed, search the file and rename it:

right click/TortoiseHg/Rename File

It will rename the file to the right case sensitive name you want. The next picture shows how i changed XMLConverter for XmlConverter

Then in the Workbench you may commit the file change:

This was updated a week later

The solution presented may gives you problems later updating the whole repository from another PC. So the ultimate way to resolve it, may be making 2 commits:

1. One for renaming files with the unwanted name to some temporary one. Ex.: XMLConverter2
2. Another for renaming the temporary files to the new names. Ex.: XmlConverter

So it got like this:

This is actually the way it doesnt make conflicts in Windows anymore. It looks ugly but it is effective.

Solution 4

To get a case folding issue on windows I'm guessing that you've got the differing cases in different branches or heads in the repo, and it becomes a problem when merging. I can't see how (on Windows) you would actually get two different cases in the same revision without going via a unix box.

So, if they are in different revisions then you can do something like this:

hg update <some rev>
hg remove -A -f "Some File"

then the merge would succeed ok. The -A is for 'after', and the -f will 'force'.

Solution 5

I solved in a simpler way:

1. List item
2. Cut the renamed folder file and paste it on a temporary location (i.e. Desktop)
3. Commit the "R" changes
4. Paste the folder again
5. Commit the "?" status

What it's really causing the problem is trying to create and delete at the same time a file/folder that is potentially the same in case unsensitive systems.

View more solutions