MQ performance on large repo

Adrian Buehlmann adrian at cadifra.com
Wed Mar 3 10:52:08 CST 2010


On 02.03.2010 21:27, Greg Ward wrote:
> 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.  ;-(

Does http://selenic.com/repo/hg-stable/rev/d5bd1beff794 improve this?


More information about the Mercurial-devel mailing list