Martin von Zweigbergk <martinvonz@google.com> [Tue, 11 Nov 2014 10:16:54 -0800] rev 23257
context.status: explain "caching reasons" more fully
Where we "load earliest manifest first for caching reasons", elaborate
on what "caching reasons" refers to. Text provided by Matt in
http://thread.gmane.org/gmane.comp.version-control.mercurial.devel/73235/focus=73578.
Augie Fackler <raf@durin42.com> [Tue, 11 Nov 2014 10:35:06 -0500] rev 23256
localrepo: rename revlog.maxchainlen to format.maxchainlen
This is more consistent with other option names, as spotted by Pierre-Yves. Thanks!
Mateusz Kwapich <mitrandir@fb.com> [Thu, 06 Nov 2014 14:20:05 -0800] rev 23255
revlog: add config variable for limiting delta-chain length
The current heuristic for deciding between storing delta and full texts
is based on ratio of (sizeofdeltas)/(sizeoffulltext).
In some cases (for example a manifest for ahuge repo) this approach
can result in extremely long delta chains (~30,000) which are very slow to
read. (In the case of a manifest ~500ms are added to every hg command because of that).
This commit introduces "revlog.maxchainlength" configuration variable that will
limit delta chain length.
Mateusz Kwapich <mitrandir@fb.com> [Thu, 06 Nov 2014 14:08:25 -0800] rev 23254
debugrevlog: fix computing chain length in debugrevlog -d
The chain length was computed correctly only when generaldelta
feature was enabled. Now it's fixed.
When generaldelta is disabled the base revision in revlog index is not
the revision we have delta against - it's always previous revision.
Instead of incorrect chainbaseandlen in command.py we are now using two
single-responsibility functions in revlog.py:
- chainbase(rev)
- chainlen(rev)
Only chainlen(rev) was missing so it was written to mimic the way the
chain of deltas is actually found during file reconstruction.