What happened: When plan9front is cloned with hg clone https://code.google.com/p/plan9front/ on OS X, the clone fails with: updating to branch default abort: case-folding collision between rc/bin/kill and rc/bin/Kill

HFS+ is case-insensitive and case-preserving by default.

What was expected: No files with identical names except for case in the repository.

Steps to reproduce: 0. Use OS X 10.9.5 or equivalent 1. Clone repo with hg clone https://code.google.com/p/plan9front/ 2. Cloning fails

There's also: abort: case-folding collision between sys/lib/postscript/troff/Hx and sys/lib/postscript/troff/HX

Get a real computer.

You're killing me, guys:

abort: case-folding collision between sys/lib/troff/font/devutf/Hb and sys/lib/troff/font/devutf/HB abort: case-folding collision between sys/lib/troff/font/devutf/Hi and sys/lib/troff/font/devutf/HI abort: case-folding collision between sys/lib/troff/font/devutf/Hx and sys/lib/troff/font/devutf/HX abort: case-folding collision between sys/lib/troff/font/devutf/charlib/lH and sys/lib/troff/font/devutf/charlib/LH abort: case-folding collision between sys/lib/troff/font/devutf/charlib/rc and sys/lib/troff/font/devutf/charlib/RC abort: case-folding collision between sys/lib/troff/font/devutf/charlib/rh and sys/lib/troff/font/devutf/charlib/rH abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c1 and sys/src/cmd/postscript/devpost.add/C1 abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c2 and sys/src/cmd/postscript/devpost.add/C2 abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c3 and sys/src/cmd/postscript/devpost.add/C3

Could someone remove the conflicting files?

Get a real computer.

Come on. It costs you nothing. It's not a compromise of principles like adding Berkeley Sockets or something. It's allowing someone to compile your code.

And it costs you NOTHING.

Just set your OS to case sensitive, as it should be. Next, people will demand 8.3 compatible file names so that they compile on DOS.

How are you even planning on compiling 9front on OS X? gcc can "mostly" compile Plan 9 code (i.e. "only" a couple errors per KLOC), llvm can not at all (i.e. there is no hope).

Come on. It costs you nothing.

this is wrong, it would cost us a lot. the plan 9 file systems are case sensitive. you are using a crippled file system on another os. the problem is not with plan 9, the problem is that you are using a case-insensitive file system. as aiju pointed out, all you have to do is turn on case-sensitivity in your file system. it costs you nothing and it requires no changes to plan 9.

Just set your OS to case sensitive, as it should be. Next, people will demand 8.3 compatible file names so that they compile on DOS.

That's the slippery slope fallacy, and it's wrong. There's a huge difference between renaming 10 files, and forcing DOS compatibility on the entire repository. DOS is a 30 year old system, and demanding that Plan 9 be--not only cloneable--but COMPILABLE on DOS is a completely unreasonable request.

As it stands, I can't even view the source on OS X except through the Google Code source browser, because 10 files have similar names. It's not unreasonable to avoid case collisions, or allow the repository to be checked out on a case sensitive filesystem like the current versions of OS X and winblows use. I can't even begin to attempt to compile Plan 9 using some clever method unless you let me check out the source.

all you have to do is turn on case-sensitivity in your file system This can't be done for HFS+ without repartitioning, i.e. wiping my HD. And a fair amount of OS X software breaks with case sensitivity. I'm not defending this, it's just a fact. I have one laptop, and I simply want to clone Plan 9.

this is wrong, it would cost us a lot. the plan 9 file systems are case sensitive. you are using a crippled file system on another os. No it wouldn't. It would cost nothing more than renaming 10 files (or removing any that are extraneous). This isn't about dropping case-sensitivity at all. This is merely allowing the repo to be viewed on case sensitive systems.

And 9/10 of these conflicts are between identical files:

abort: case-folding collision between sys/lib/postscript/troff/Hx and sys/lib/postscript/troff/HX abort: case-folding collision between sys/lib/troff/font/devutf/Hb and sys/lib/troff/font/devutf/HB abort: case-folding collision between sys/lib/troff/font/devutf/Hi and sys/lib/troff/font/devutf/HI abort: case-folding collision between sys/lib/troff/font/devutf/Hx and sys/lib/troff/font/devutf/HX abort: case-folding collision between sys/lib/troff/font/devutf/charlib/lH and sys/lib/troff/font/devutf/charlib/LH abort: case-folding collision between sys/lib/troff/font/devutf/charlib/rc and sys/lib/troff/font/devutf/charlib/RC abort: case-folding collision between sys/lib/troff/font/devutf/charlib/rh and sys/lib/troff/font/devutf/charlib/rH abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c1 and sys/src/cmd/postscript/devpost.add/C1 abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c2 and sys/src/cmd/postscript/devpost.add/C2 abort: case-folding collision between sys/src/cmd/postscript/devpost.add/c3 and sys/src/cmd/postscript/devpost.add/C3

alexchandel: this isn't an osx support group. nobody has any interest in making changes to plan 9 to support doing [who knows what] to its files on an unsupported operating system. it's not plan 9's fault you installed your osx file system without case sensitivity. just make better choices in the future. and get better tools.

stanley: I'm not asking for an "osx support group" or any other red herring you came up with. The changes I proposed are quite unremarkable, and involve removing duplicated files. And they allow the source code to be cloned onto a case insensitive filesystem.

You could indulge an interested person with a trivial change allowing them to view source code, or you could rebuff them from the community with crass suggestions to "Get a real computer," or join "an osx support group," or "just make better choices in the future" and install "your osx file system without case sensitivity." Implying I ever installed this file system, or can format this computer's HD.

abort: case-folding collision between rc/bin/kill and rc/bin/Kill

you're asking for more than just removing duplicate files. you're asking to restrict plan 9 file systems to case-insensitive behavior because you want to hg clone the 9front repo onto a case-insensitive file system. we don't support hg clone of the 9front repo onto case-insensitive file systems. it's really that simple. you've dug up an example of duplicate files that probably shouldn't exist, but you're now ignoring your own other examples such as Kill vs kill where the conflict is not caused by useless duplicates. how do you propose to address the Kill vs kill conflict?

thanks for filing all these bug reports, but nobody here is getting paid to indulge interested persons. or to validate your complaints, no matter how many times you repeat them.

this is not just duplicated files. you need to change tr2post and come up with a mangeling scheme. and stuff doesnt stop here. the problem is that mercurial cannot unpack with these collisions. tho it goes to great lengths mangeling the filenames of the repository revlogs. maybe they'll fix this or provide an option at some point. but nobody is going and make the 9front tree macosx compliant. it is just too much trouble. if you want access to the source, you could just take it from the iso. it contains everything unpacked already.

you're asking to restrict plan 9 file systems to case-insensitive behavior No, I wasn't. Saying it multiple times doesn't make it true.

this is not just duplicated files. you need to change tr2post and come up with a mangeling scheme. cinap: Thank you for actually explaining the issue.

Inspired by the ISO suggestion, I created a case-sensitive disk image and cloned the repo into that. Problem solved. This is probably a good suggestion for future users with this problem.

Another solution if you only have one computer is to just install 9front in a VM. Then not only can you look at the code, but you can compile and run it easily.

Plan 9 is about 10 years older than OS X. More than that, Plan 9 was designed with little to no concern for the norms and standards of Unix as it existed outside Bell Labs. It's just not like any unix or even any other OS; in places it takes approaches to problems which surprise most everyone. You're not going to get much out of it by just looking at the code.

I'd second hiro's suggestion; install it in a VM where you can both try it and look at the code. Plan 9's plumber makes it simple to open files listed by ls or from the output of grep where the editor will jump to the line number given by grep. Plan 9's coding style makes it easy to find function definitions: grep -n '^funcname(' *.c

If you really only want to look at the code without getting in so deep, I suggest looking at plan9port instead, it's developed on OS X.

For the record:

Those files are present for good reason and this is not a problem. They will not ever be removed or renamed.