I'm wrong, the decodefunction doesn't really matter, sorry.

We should have done something like that in the first place:

diff --git a/mercurial/store.py b/mercurial/store.py
--- a/mercurial/store.py
+++ b/mercurial/store.py
@@ -51,7 +51,15 @@
                 except KeyError:
                     pass
             else:
-                raise KeyError
+                if s[i] != '~':
+                    raise KeyError
+
+                try:
+                    val = int(s[i + 1: i + 3], 10)
+                except ValueError:
+                    raise KeyError
+                yield chr(val)
+                i += 3
     return (lambda s: "".join([cmap[c] for c in encodedir(s)]),
             lambda s: decodedir("".join(list(decode(s)))))
 

That would allow us to add new patterns to encode

In order to fix this bug, it would seem so. On the Mercurial list, Adrian 
Buehlmann mentioned a similar Windows bug, filed as issue1713.

I don't know much about how fncache actually works, but it seems to me that it 
would be preferable to avoid ever creating files whose names begin with a dot 
or a space. While ‘.[^_]*’ should be safe, such files are normally hidden in 
shells, and that seems inappropriate for the store.

Ugh, we have to rev the store version again?

I'd consider this a bug in Mercurial; dot-underscore files are generally 
treated specially on Mac OS X, and the ‘fncache’ repository storage shouldn't 
generate those.

I took the liberty of changing the priority to »bug«.

That makes a lot of sense and is consistent with what I've seen. It probably
makes sense for mercurial to automatically ignore 'resource fork' files
since they don't contain user (directly) created data. It would make the
repository more robust.

I have a call in to Apple to try to find out what they are actually backing
up via Time Machine - where I don't see any dot files of any kind.

The Mac stores the "resource fork" of files in a file prefixed with "._", on
filesystems that don't support resource forks natively (e.g. SMB). See

http://en.wikipedia.org/wiki/Resource_fork

In general dot-files should be OK, however, there are probably a bunch of
special cases in the Mac code where the "._" prefix is treated specially.

This is a low frequency event, but a real pain in the butt.

At least one of my hg repositories was corrupted after purchasing a new
macbook and using Apple's automatic copy-your-old-system-to-your-new-one.

Specifically, about 6 files beginning with ._ are missing. These are mostly
named ._ds_store.i and ._bridgesort. [they probably shouldn't have been
there to begin with, but I was new to mercurial]. They are in a backup I
made using 'cp'. [All other dot files seem to be OK - so it's obviously
something in Apple's strange mind]

I tried restoring them by copying from the backup copy on the external disk,
but 'hg verify' is still upset.

Suggest considering an alternate naming convention which avoids leading dot's.

I've a call into Apple to try to find out what is going on from their point
of view.