> Patrick Mézard <pmezard@gmail.com> added the comment:
>
> As you can guess I do not have the kind of hardware to reproduce this. Could
> you try to pinpoint the hg revision where the file reappear and past its
> "log --debug" here?

You certainly won't need that hardware (I don't think hg can make use of
the multiple CPUs anyway, and the memory didn't help either since I've
been restricted by the 32-bit binaries used), but still the diskspace
consumption is considerable.  My 12 GB figure is too low, anyway, since
the sources are stored on ZFS with compression enabled, I think the
uncompressed value is in the 19 GB range.

Anyway, hg log -v only shows a single revision (the one the file was
added):

$ hg log -v gcc/testsuite/gcc.dg/20021205-1.c 
changeset:   46469:c99a48846e8c
user:        dalej
date:        Fri Dec 06 00:08:11 2002 +0000
files:       gcc/ChangeLog gcc/testsuite/gcc.dg/20021205-1.c gcc/tree.c
description:
2002-12-05  Dale Johannesen  <dalej@apple.com>

        * tree.c (unsafe_for_reeval):  Consider callee child of CALL_EXPR.

Obviously, the move wasn't tracked for some reason.  hg log --debug
gives

$ hg log -r46469 --debug gcc/testsuite/gcc.dg/20021205-1.c 
changeset:   46469:c99a48846e8c5a0585e3f8c818886cfd5e74bc62
parent:      46468:c2e9014ec3c6aceaa43500ed59cd26ae52bccc88
parent:      -1:0000000000000000000000000000000000000000
manifest:    46469:1c33f198ba5753d21cbf934bb8f120e1272d1cda
user:        dalej
date:        Fri Dec 06 00:08:11 2002 +0000
files:       gcc/ChangeLog gcc/tree.c
files+:      gcc/testsuite/gcc.dg/20021205-1.c
extra:       branch=default
extra:       convert_revision=svn:138bc75d-0d04-0410-961f-82ee72b054a4/trunk@59875
description:
2002-12-05  Dale Johannesen  <dalej@apple.com>

        * tree.c (unsafe_for_reeval):  Consider callee child of CALL_EXPR.

The file was moved here:

$ hg log -v -r46564 gcc/testsuite/gcc.c-torture/compile/20021205-1.c
changeset:   46564:8c866ffe0ea5
user:        dalej
date:        Sat Dec 14 00:54:02 2002 +0000
files:       gcc/testsuite/gcc.c-torture/compile/20021205-1.c
description:
Fix test for LP64, move it to gcc.c-torture/compile (per Kaveh Ghazi)

$ hg log -v -r46564 --debug gcc/testsuite/gcc.c-torture/compile/20021205-1.c
changeset:   46564:8c866ffe0ea5ec8be343a955b32849b89e5376b0
parent:      46563:0f132e6cd86d38df2cedaeb07b7ea4d3f08d1614
parent:      -1:0000000000000000000000000000000000000000
manifest:    46564:d0d749899a1ef35f838c1c5a42b3cb7e0e4f48c4
user:        dalej
date:        Sat Dec 14 00:54:02 2002 +0000
files+:      gcc/testsuite/gcc.c-torture/compile/20021205-1.c
extra:       branch=default
extra:       convert_revision=svn:138bc75d-0d04-0410-961f-82ee72b054a4/trunk@60111
description:
Fix test for LP64, move it to gcc.c-torture/compile (per Kaveh Ghazi)

Hope this helps.

     Rainer

As you can guess I do not have the kind of hardware to reproduce this. Could
you try to pinpoint the hg revision where the file reappear and past its
"log --debug" here?

About 150000 revisions, the local copy is ca. 12 GB.

By curiosity can you tell me how large is GCC svn repository?

I've converted the GCC svn repository to a hg repository as described in
Issue2013.  After cloning the trunk from the hg repository with

$ hg clone -rdefault ../repo dist

I ultimately noticed (after some bug hunting) that the conversion had
resurrected a file that had been renamed in svn:

gcc/testsuite/gcc.dg/20021205-1.c

(I've now checked this and it seems to be the only one.)  This is very
unfortunate if you cannot rely on the hg mirror being correct.