I see!  Yes, you are quite correct -- in my "fixed" (via the convert 
extension) the revlog of the file in question would no longer fall prey to 
Time Machine's vagaries.  Thanks for the clarification, and apologies for the 
extra noise I caused.

Johann: even if you use a new version of Mercurial, old repositories wont
upgrade themselves automatically.

The on-disk format of a repository is determined when you create it. So a
new repository created with 'hg init' and a post-1.7 Mercurial will use the
dotencode format (look in .hg/requires to confirm this).

Clones are a little more tricky: 'hg clone foo bar' will create a bar clone
with the same on-disk format as foo because of hardlinks. You need to use
'hg clone --pull foo bar' to make bar a new format clone with no hardlinks
back to foo.

I can confirm the issue with Mercurial 1.8.2 under OS X 10.6.7.

I have recently restored a hard drive from a Time Machine backup, and a 
repository that was located on said drive was corrupted after the restore.

It appears that the one particular file's revlog was just completely absent 
after the restore.  The file in question had a name starting with a dot, 
followed by a capital letter (say, ".Foo").  Hence, its revlog had a name 
starting in ._* (say, "._foo").

It appears that currently Time Machine DOES NOT BACK UP files starting in ._* 
at all!  I searched back through my time machine backups, but this particular 
revlog was never present.  (I have yet to create such a file on purpose and 
see what Time Machine does.)

One would assume that Time Machine views a file starting in ._* as an 
AppleDouble [1][2] and hence simply neglects to back it up.

For the record, I managed to recover by using the convert extension as 
described at [3].  (Fortunately it was only a private repository.)

This is clearly an Apple / Time Machine issue, not a Mercurial one.  But I 
thought I'd respond here, as it's probably more likely to get the Mercurial 
folks to come up with a workaround than it is to get Apple to change their 
ways...

[1] http://en.wikipedia.org/wiki/AppleSingle_and_AppleDouble_formats
[2] http://support.apple.com/kb/TA20578
[3] http://mercurial.selenic.com/wiki/RepositoryCorruption

I was running hg 1.7.5 before the disk died but the repositories may have
been created with earlier versions.

I'm fairly certain dotencode fixes this. It was released as part of hg 1.7.

Just ran into this issue after having to replace a failed hard drive. At
first it looked like Time Machine restored everything just fine, but a hg
verify shows that all my local repositories are now damaged. It would be
really nice if this could be addressed in some future Mercurial version ...

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.