Some open issues:

1. Would be nice if 'hg clone --rev' (without explicit --pull) would
automatically relink the new clone against the origin.

2. If you push a lot of changesets to parallel branches which get cross-merged a
lot (as NetBeans developers do), so many changesets will be stored in the two
repos in opposite local order that the opportunities for relinking will be
substantially reduced: the *.i files will differ in binary content even if the
two repos hold the exact same set of changesets. A possible solution is to have
a separate command (or option?) to first canonicalize one or both repos: rebuild
the changelog and revlogs with changesets topologically sorted with children of
a parent node traversed in e.g. date order. This would mean that revlogs for
files not touched since the last common ancestor of the two repos would be
guaranteed to have identical content on disk and could be linked.

Patch submitted to dev list.

Now documented at:

http://www.selenic.com/mercurial/wiki/index.cgi/RecreateHardlinksBetweenRepositories

Seems there is a script in contrib/hg-relink that does this. Would be preferable
to have this be a real hg command in an extension. (Among other things, Windows
users getting the all-in-one installer cannot necessarily even run a standalone
Python script.)

'hg clone -r' fails to use hardlinks even for storage files which are unchanged
relative to the origin repository. This wastes quite a bit of disk space when
creating a truncated clone which has most of the changesets as in the original.
And there are other cases where some storage files could be retroactively
hardlinked to save space.

Suggest a command 'hg hardlink' (perhaps in an extension?) which would have the
same effect as

http://www.selenic.com/mercurial/wiki/index.cgi/TipsAndTricks#head-f6c2fdd99afc10b3af2234f63eb91dda0e01145f

For example, to get a copy of a server-hosted release while minimizing both
local storage and network traffic:

hg clone -r 1.0 main release-1.0
hg -R release-1.0 pull -u http://nowhere.net/hg/release-1.0
hg hardlink main release-1.0

Probably the command can just print a warning, rather than abort with an error
code, if hardlinks are not supported between the two dirs for any reason; after
all, it is just a performance optimization, and the number of files which can
actually be hardlinked anyway is not easily predictable.

Will submit patch on request if this seems like a good idea. I have heard other
complaints that the "quick and dirty" technique is too cumbersome or scary to be
recommended.