MQ performance on large repo

[Greg Ward]

On Mon, Mar 1, 2010 at 6:31 PM, Adrian Buehlmann <adrian at cadifra.com> wrote:
> If shortly tried to think about how it is possible to force duplicate
> entries in the fncache file with the current code and failed. But I
> could swear I saw it in the past. tonfa has made some nice refactorings
> in store.py though in the past, which IMHO seem to make it harder to get
> duplicates. Do you happen to know a use case that produces duplicate
> lines in fncache? (I guess I'm too lazy right now to see it)

Well, we must be missing something.  I just re-ran the same cvs2hg
conversion three times, with hg 1.3, 1.4, and 1.5ish (current stable).
 Result: highly redundant fncache every time.

Specifically, in every case:
  * the new hg repo created by cvs2hg has 3741 files in .hg/store/data
  * there are 3875 unique lines in .hg/store/fncache (sort -u | wc -l)
  * there are 28354 total lines in .hg/store/fncache

Based on that, I conclude that strip's runtime will be dominated by
the time taken to read fncache for any repo created by cvs2hg with
Mercurial 1.3, 1.4, or 1.5.  ;-(

Greg