hg log -r 'svnrev(nnnnnn)' is very slow.

Create issue
Issue #235 resolved
koie created an issue

I'm using FreeBSD repository that is converted by hgsubversion. FreeBSD has many revisions ~157079. "wc -l .hg/svn/rev_map" shows 157081. An option -r 'svnrev(nnnn)' is very useful, but very slow.

Comments (5)

  1. Dan Villiom Podlaski Christiansen

    This is mostly by design, actually: svnrev(N) doesn't use the hgsubversion metadata, but inspects the changesets to find the ones matching the query. You might want to try combining the revset with something else to prevent it from inspecting the entire history. It would help, though, if you could provide a bit more information: what is the query that's slow? How slow is it?

  2. Augie Fackler repo owner

    Dan, if you trust that the metadata in .hg/svn is up to date, then you should be able to use the revmap instead of parsing every single changeset in the entire repo.

  3. Patrick Mézard

    This was fixed by:

    changeset:   889:7a98fbadcae9
    user:        Bryan O'Sullivan <bryano@fb.com>
    date:        Sat May 12 05:38:34 2012 -0700
    files:       hgsubversion/maps.py hgsubversion/util.py
    revsets: huge speedups for fromsvn and svnrev
    I have a hgsubversion repo that contains over 300,000 commits.
    In that repo, this patch improves performance as follows:
    hg --time log -r 'first(fromsvn())'
    Before: 40.3 sec
    After:   0.8 sec
    hg --time log -r 'svnrev(350000)'
    Before: 40.3 sec
    After:   0.1 sec
    Note: the performance of these revset implementations is very sensitive
    to doing as little work as possible per line of the rev_map file.
    I originally attempted to hide the file format details by hoisting the
    parsing of each line up into RevMap.readmapfile, but the current less
    abstract code is dramatically (10x or more) faster.
    If the revmap file is missing, we error out and print a message
    describing what to do.
  4. Log in to comment