umlauts in file names between OSX and Windows

[Mads Kiilerich]

On 01/04/2011 11:54 AM, Jouni Airaksinen wrote:
> OK Thanks. Not sure though how is the extension supposed to help with
> the problem in OSX. I noticed that in OSX Mercurial thinks the file is
> new (?) but doesn't show missing file (!) until the "new" file is
> removed. So somehow it's linking the file as the correct one even though
> status tells otherwise.

I assume your problem is caused by OSX performing utf8 normalization of 
filenames that isn't utf8 at all. See 
http://mercurial.selenic.com/bts/issue1080 and 
http://mercurial.selenic.com/wiki/EncodingStrategy .

Making sure filenames are stored in utf8 and not in some 8 bit encoding 
might solve your problems. But I'm also not sure ;-)


Some more details could help us understand the problem.

How is the windows filename encoded in .hg/store/data/ ?

Exactly how do the status output with new/missing file look like?

How is the new filename encoded in .hg/store/data/ if you run addremove 
and commit on OSX?

> Regarding the extensions not included with Mercurial.. anyone has good
> enterprise pattern to handle extensions and hooks distribution?
> Especially when there is mix of Windows, OSX and Linux users. Windows
> users seem the have the most problems because of ie. Eclipse has it's
> own HG. I've tried to instruct not to use the bundled hg but
> TortoiseHg's Hg, but then again it's whole python and stuff in one
> package so extensions have to be absolute paths and cannot easily use
> modules not included in TortoseHg package. It's also very labourous to
> handle the hgrc settings manually for each user. I have to inspect the
> %include, but Windows users generally would prefer the GUI stuff for all
> settings and rest, so I have to provide some template hgrc (and updates
> into it) to "enforce" proper setup. That said I really welcome the
> relative paths fix for hooks though.

Building your own installers might be the best solution.

/Mads