How to solve a Mercurial case-folding collision?
Asked Answered
C

6

5

I use Mercurial as source control with the main repository managed on KILN. At one point in time I changed my iOS project name from WeatherTimeMachine to weathertimemachine. This resulted in a case change of several files and folders:

  • WeatherTimeMachine.xcode
  • WeatherTimeMachine_Prefix.pch
  • WeatherTimeMachine-Info.plist

In the meantime I've added a tag to a revision in KILN... So I now have:

  • a head in KILN
  • a head on my local repo with case changes

When trying to merge I get the following error message: "Mercurial case-folding collision"

How can I fix this?

Coppinger answered 29/9, 2011 at 9:54 Comment(0)
C
5

I have found some information here: FixingCaseCollisions, but somehow this did not work for me. Here is how I managed to solve this issue:

Make a copy of your existing repository folder (for safety). For example:

  • cp -r WeatherTimeMachine WeatherTimeMachineCopy

Fool mercurial into thinking the problematic revision is the current tip:

  • hg debugsetparents <bad revision>
  • hg debugrebuildstate

Remove the files which are causing the problem (-f is required to force the removal). Here is an example:

  • hg rm -A -f WeatherTimeMachine-Info.plist

Once all problematic files have been removed, commit the changes

  • hg ci -m "fixed collision-folding issue" -u michael

Then restore mercurial to the proper revision

  • hg debugsetparents tip
  • hg debugrebuildstate

After this the merge is possible and the problem is gone.

And now I can happily resume working with MacHg to manage my Mercurial repository and push my change sets to KILN.

Coppinger answered 29/9, 2011 at 10:5 Comment(1)
I have tried the approach provided through the link you mentioned as well as your variant of that approach and neither work, they both just end in directory of missing files and when I try to force a merge, Hg tells me that the case-folding collision still exists.Embarkment
U
6

If you're on Mac OS X, you don't need to export your repository to Linux or another foreign case-sensitive file system as suggested by the Mercurial documentation. Just use Disk Utility to create a case-sensitive, journaled disk image slightly bigger than your repository, copy your repo there, then remove the conflicting files and commit.

Untaught answered 15/2, 2012 at 16:31 Comment(0)
C
5

I have found some information here: FixingCaseCollisions, but somehow this did not work for me. Here is how I managed to solve this issue:

Make a copy of your existing repository folder (for safety). For example:

  • cp -r WeatherTimeMachine WeatherTimeMachineCopy

Fool mercurial into thinking the problematic revision is the current tip:

  • hg debugsetparents <bad revision>
  • hg debugrebuildstate

Remove the files which are causing the problem (-f is required to force the removal). Here is an example:

  • hg rm -A -f WeatherTimeMachine-Info.plist

Once all problematic files have been removed, commit the changes

  • hg ci -m "fixed collision-folding issue" -u michael

Then restore mercurial to the proper revision

  • hg debugsetparents tip
  • hg debugrebuildstate

After this the merge is possible and the problem is gone.

And now I can happily resume working with MacHg to manage my Mercurial repository and push my change sets to KILN.

Coppinger answered 29/9, 2011 at 10:5 Comment(1)
I have tried the approach provided through the link you mentioned as well as your variant of that approach and neither work, they both just end in directory of missing files and when I try to force a merge, Hg tells me that the case-folding collision still exists.Embarkment
F
5

This is a no-programming no-hg answer, but it solved my mercurial case-folding problems once and for all! For now anyway..

I gave up trying to avoid and "fix" the case-collision problems. That just looks ugly and you can never really "solve" the problem, only can do a workaround.

The only way (that I can think of) to really solve the problem is to have a case-sensitive filesystem. No need to reformat your entire disk, a single partition will do the job nicely.

I used the Disk Utility app that comes with the os, pretty straightforward, just remember to select Mac OS Extended (Case-sensitive, Journaled) when creating new partition. Also, note that the Disk Utility can resize partitions only by moving the end (not the beginning) of partition.

You can probably create a symlink to where your old source code lived, so no need to change the IDE settings and stuff (but I haven't tried this, just happy with the new partition).

Fideicommissum answered 21/11, 2012 at 12:25 Comment(0)
A
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.

Amaurosis answered 3/5, 2013 at 15:9 Comment(1)
Not if you already have a case-folding collision situation committed in the repository (somewhere in history). For example if you pulled it from someone who has case-sensitive filesystem. At least not that simple anyways :(Fideicommissum
B
0

For Mac OS X, what worked for me is to simply copy the folder (duplicate works - cmd-D) and continue working on it, from the new path.

Bimonthly answered 10/7, 2014 at 3:20 Comment(0)
C
0

OSX same I wanted to clone a repo and I had case-folding error preventing me top clone.

If the repository has multiple commit simply clone an earlier revision with this command:

hg clone -r 7

Then add anything conflicting to the .hgignore file and update.

Costrel answered 23/1, 2017 at 16:34 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.