Skip to content

lookup for Mercurial short nodes in Notes

This rough experiment provides #343 (closed), but needs more time for inclusion. Like the parent changeset, it does not provide migration for previously rendered Notes

The CommitReferenceFilter class is the one responsible for the rendering.

We're adding resolution of truncated Mercurial node ids for the case of the hg_git VCS type, relying on the existing map of full Mercurial SHA (Node id) to Git SHA.

This has too much impact to make it into Heptapod 0.16.0, which is around the corner: while the Git::Commit.batch_by_oid method doesn't seem to be called except from the #commits_by method of the Repository mode, the latter is used in several places of the application, with risks of breakage and/or severe performance degradation.

This is very inefficient, and proper calls with low startup overhead to a persistent Mercurial nodemap would do much better above a certain repository size (persistent nodemap is provided by Rust native extensions, and low overhead would be achieved only by a fastpath without Python or a long-running process, such as HGitaly)

Preliminary performance analysis (non scientific, on my workstation) shows that in the 100k changesets range (pypy repo) this naive lookup takes about 30ms, whereas hg log -T is in the 100-200ms ballpark. Around 500k changesets (mozilla-central repo), times have the same order of magnitude (around 100-200ms again). To insist, this is with the hg startup overhead and without the Rust persistent nodemap (would take less than 1ms). We fully expect the current hg<->git maps to be an unbereable performance problem in Heptapod anyway around 500k to 1M changesets anyway, only solved by HGitaly.

All in all, the performance question seems to be acceptable in the current inefficient context for Note rendering. HGitaly would provide an efficient RPC call anyway.

Closes #202 (closed)

Edited by Georges Racinet

Merge request reports