D6613: commit: improve the files field of changelog for merges (RFC)
valentin.gatienbaron (Valentin Gatien-Baron)
phabricator at mercurial-scm.org
Mon Jul 8 23:03:17 EDT 2019
valentin.gatienbaron added a comment.
I hadn't seen the bug you linked to, or your recent change, though I saw ctx.filesadded() and friends (when writing this) and suspected they were written the way they are to work nicely on merges.
I didn't have one single goal when writing this. Hg's behavior is the source of several problems.
One problem is the size of the changelog and bundles. In part because I assume this creates slowness (hg log -u .. for instance), but also because things look broken as a result: the changelog is bigger than the manifestlog, some bundles consist almost purely of this list of files. I can't really analyze these parts of hg until this is fixed because this problem would shadow everything else.
I estimate that the changelog would be half the size with this (75% of the changelog taken by files list, 65% of uncompressed files list size come from merges, lists for merge get 60x shorter, and I assume compression ratio wouldn't get too much worse when shortening these files lists), if I could rewrite the history without changing hashes.
Then a couple of weeks ago, I looked at the speed of hg pull. I noticed that server-side hg was opening 35k filelogs when it really needed 12k (~50% server time doing that IIRC). Adding the filtering from this commit into the server-side of pull made it open 13k filelogs, which sounds like a reasonable number (I can't measure whether pull time would be improved given the cost of filtering on the fly, but it certainly wouldn't be any worse).
Finally, I realized that hg log can show seemingly random merge commits because of this, which makes me think this is probably causing other problems that I haven't identified yet.
CHANGES SINCE LAST ACTION
To: valentin.gatienbaron, #hg-reviewers
Cc: martinvonz, mjpieters, mercurial-devel
More information about the Mercurial-devel