When files or dirs are renamed in Hg, repository size is increased, I guess by
about the compressed size of those files:

$ hg init
$ cp /boot/vmlinuz-2.6.22-14-generic f
$ hg add f
$ hg ci -m 1
$ du --si
1.8M	./.hg/store/data
1.8M	./.hg/store
1.8M	./.hg
3.6M	.
$ hg ren f g
$ hg ci -m 2
$ du --si
3.5M	./.hg/store/data
3.5M	./.hg/store
3.5M	./.hg
5.3M	.
$ ls -Rl .hg/store/data
.hg/store/data:
total 3328
-rw-r--r-- 1 jglick jglick 1692145 2007-11-09 05:42 f.d
-rw-r--r-- 1 jglick jglick      64 2007-11-09 05:42 f.i
-rw-r--r-- 1 jglick jglick 1692204 2007-11-09 05:42 g.d
-rw-r--r-- 1 jglick jglick      64 2007-11-09 05:42 g.i

For a repository which is already hundreds of megabytes, doing major source
reorganizations is out of the question for this reason. This is a serious
drawback compared to Subversion; or even arguably to CVS, where moving a dir
means you only pay a penalty in history, not future usage.

mpm has written regarding implementation:

"Currently fixing the renaming issue would present a layering
violation. That is, individual revlogs have no knowledge of any other
revlog. So when we ask a revlog to retrieve version <x> of some file,
it has to have all the data internally."