Wed, 18 Nov 2015 15:18:16 -0800 unshelve: shed spurious space
Siddharth Agarwal <sid0@fb.com> [Wed, 18 Nov 2015 15:18:16 -0800] rev 27020
unshelve: shed spurious space
Wed, 18 Nov 2015 15:04:03 -0800 unshelve: add -k as short form of --keep
Siddharth Agarwal <sid0@fb.com> [Wed, 18 Nov 2015 15:04:03 -0800] rev 27019
unshelve: add -k as short form of --keep For parity with strip -k, rebase -k, etc.
Sun, 01 Nov 2015 13:55:21 +0900 import-checker: allow symbol imports from hgweb.common and .request
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Nov 2015 13:55:21 +0900] rev 27018
import-checker: allow symbol imports from hgweb.common and .request This seems the convention of hgweb.
Thu, 19 Nov 2015 15:02:27 -0600 perf: un-bitrot perfstatus
Matt Mackall <mpm@selenic.com> [Thu, 19 Nov 2015 15:02:27 -0600] rev 27017
perf: un-bitrot perfstatus
Thu, 19 Nov 2015 13:15:17 -0600 util: drop statmtimesec
Matt Mackall <mpm@selenic.com> [Thu, 19 Nov 2015 13:15:17 -0600] rev 27016
util: drop statmtimesec We've globablly forced stat to return integer times which agrees with our extension code, so this is no longer needed. This speeds up status on mozilla-central substantially: $ hg perfstatus ! wall 0.190179 comb 0.180000 user 0.120000 sys 0.060000 (best of 53) $ hg perfstatus ! wall 0.275729 comb 0.270000 user 0.210000 sys 0.060000 (best of 36)
Thu, 19 Nov 2015 13:21:24 -0600 util: disable floating point stat times (issue4836)
Matt Mackall <mpm@selenic.com> [Thu, 19 Nov 2015 13:21:24 -0600] rev 27015
util: disable floating point stat times (issue4836) Alternate fix for this issue which avoids putting extra function calls and exception handling in the fast path. For almost all purposes, integer timestamps are preferable to Mercurial. It stores integer timestamps in the dirstate and would thus like to avoid doing any float/int comparisons or conversions. We will continue to have to deal with 1-second granularity on filesystems for quite some time, so this won't significantly hinder our capabilities. This has some impact on our file cache validation code in that it lowers timestamp resolution. But as we still have to deal with low-resolution filesystems, we're not relying on this anyway. An alternate approach is to use stat[ST_MTIME], which is guaranteed to be an integer. But since this support isn't already in our extension, we can't depend on it being available without adding a hard Python->C API dependency that's painful for people like yours truly who have bisect regularly and people without compilers.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip