Mon, 10 Nov 2014 14:51:18 -0800 add: add back forgotten files even when not matching exactly (BC)
Martin von Zweigbergk <martinvonz@google.com> [Mon, 10 Nov 2014 14:51:18 -0800] rev 23258
add: add back forgotten files even when not matching exactly (BC) I accidentally did 'hg forget .' and tried to undo the operation with 'hg add .'. I expected the files to be reported as either modified or clean, but they were still reported as removed. It turns out that forgotten files are only added back if they are listed explicitly, as shown by the following two invocations. This makes it hard to recover from the mistake of forgetting a lot of files. $ hg forget README && hg add README && hg status -A README C README $ hg forget README && hg add . && hg status -A README R README The problem lies in cmdutil.add(). That method checks that the file isn't already tracked before adding it, but it does so by checking the dirstate, which does have an entry for forgotten files (state 'r'). We should instead be checking whether the file exists in the workingctx. The workingctx is also what we later call add() on, and that method takes care of transforming the add() into a normallookup() on the dirstate. Since we're changing repo.dirstate into wctx, let's also change repo.walk into wctx.walk for consistency (repo.walk calls wctx.walk, so we're simply inlining the call).
Tue, 11 Nov 2014 10:16:54 -0800 context.status: explain "caching reasons" more fully
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.
Tue, 11 Nov 2014 10:35:06 -0500 localrepo: rename revlog.maxchainlen to format.maxchainlen
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!
Thu, 06 Nov 2014 14:20:05 -0800 revlog: add config variable for limiting delta-chain length
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.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -4 +4 +10 +30 +100 +300 +1000 +3000 +10000 tip