umlauts in file names between OSX and Windows
Jouni Airaksinen
Jouni.Airaksinen at descom.fi
Tue Jan 4 06:39:44 CST 2011
Seems to be all in the links you provided.
Probably would be more useful with hexdumps, however:
OSX file with hg add/remove store/data:
-rw-r--r-- 1 jouni staff 72 3 Tam 16:40 a~cc~88ssa~cc~88.txt.i
file name was "ässä.txt"
hg status works fine. Although typing in the file names is a bit
problematic. You can create the files fine, but while testing I ended up
with problem that I had added the file (not committed) with hg add and
then physically removed the file. Now I cannot do "hg rm" because the
existing file names aren't that easy to type in for some reason in the
shell. tab autocomplete works though.
The Windows stored (originally from SVN through hg convert in OSX)
store/data:
-rw-r--r-- 1 jouni staff 53382 3 Tam 15:53 v~c3~a4rit.psd.i
file name was "värit.psd"
Cloning/updating this file creates proper file in OSX (Finder shows it
correctly) and in shell it looks something like this:
"vä rit.psd"
hg status shows just:
? vä rit.psd
And if I remove the file physically hg status shows:
! vä rit.psd
So the file kind of exists for mercurial when checking missing files, but
not matched with untracked files.
I guess just have to tell (remind) everybody "DONT" for non us-ascii file
names. Subversion seems to suffer same issue, although shows the files as
untracked AND missing. You would think that this kind of thing would work
in 2011.. :)
ps. Not sure if the umlauts in the email are received in your end (let me
know).
pps. sorry about the Lotus Notes mail client rubbish on replies..
From: Mads Kiilerich <mads at kiilerich.com>
To: Jouni Airaksinen <Jouni.Airaksinen at descom.fi>
Cc: mercurial at selenic.com
Date: 04.01.2011 14.02
Subject: Re: umlauts in file names between OSX and Windows
Sent by: mercurial-bounces at selenic.com
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
_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110104/f55d170c/attachment.htm>
More information about the Mercurial
mailing list