Sun, 21 May 2017 15:56:02 +0200 hidden: drop outdated comment about "dynamic" performance
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 21 May 2017 15:56:02 +0200] rev 32480
hidden: drop outdated comment about "dynamic" performance This comment is now irrelevant since we have a faster algorithm and no cache.
Sun, 21 May 2017 15:47:06 +0200 hidden: unify the static and dynamic blocker logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 21 May 2017 15:47:06 +0200] rev 32479
hidden: unify the static and dynamic blocker logic We no longer have cache and they both work the same way. Unifying the logic simplify the code and reduce the amount of set copies.
Sun, 21 May 2017 15:53:08 +0200 hidden: drop the hidden cache logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 21 May 2017 15:53:08 +0200] rev 32478
hidden: drop the hidden cache logic The improvement in time complexitty and the speed-up in computation is large enough that the has little use now. Its update time can even gets in the way. So we drop it. This will allow us to unify the static/dynamic blockers logic in the next changeset.
Sun, 21 May 2017 16:01:20 +0200 hidden: simplify the computation of consistency blocker
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 21 May 2017 16:01:20 +0200] rev 32477
hidden: simplify the computation of consistency blocker For a couple of years, we now have precomputed set for all mutable phases. We can use this set restrict our search and quickly detect non-hideable children of hideable changesets. This speeds up the hidden computation. See docstring of the new function for details. This new version reuses the '_domainancestors' function to keep the computation of revealed changeset in O(len(visible)) Below are perfvolatilesets timing from two Mozilla repositories with different contents. hidden cache is disabled while obtaining them. 1) Mozilla repository with: * 400667 changesets * 35 hidden changesets (first rev-268334) * 288 visible drafts * 1 unstable changeset Before: ! visible ! wall 0.001744 comb 0.000000 user 0.000000 sys 0.000000 (best of 1563) After: ! visible ! wall 0.000742 comb 0.000000 user 0.000000 sys 0.000000 (best of 3755) The timing above include the computation of obsolete changeset: ! obsolete ! wall 0.000396 comb 0.000000 user 0.000000 sys 0.000000 (best of 6816) So adjusted time give 1.3ms before versus 0.3ms after. A 4x speedup. 2) Mozilla repository with: * 405645 changesets * 4312 hidden changesets (first rev-326004) * 264 visible drafts * 1 unstable changeset Before: ! visible ! wall 0.025476 comb 0.030000 user 0.030000 sys 0.000000 (best of 111) After ! visible ! wall 0.007703 comb 0.010000 user 0.010000 sys 0.000000 (best of 358) The timing above include the computation of obsolete changeset: ! obsolete ! wall 0.006408 comb 0.010000 user 0.010000 sys 0.000000 (best of 404) So adjusted time give 19ms before versus 1.3ms after. A 17x speedup.
Sun, 21 May 2017 15:35:21 +0200 hidden: use _domainancestors to compute revs revealed by dynamic blocker
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 21 May 2017 15:35:21 +0200] rev 32476
hidden: use _domainancestors to compute revs revealed by dynamic blocker The complexity of computing the revealed changesets is now 'O(revealed)'. This massively speeds up the computation on large repository. Moving it to the millisecond range. Below are timing from two Mozilla repositories with different contents: 1) mozilla repository with: * 400667 changesets * 35 hidden changesets (first rev-268334) * 288 visible drafts * obsolete working copy (dynamicblockers), Before: ! visible ! wall 0.030247 comb 0.030000 user 0.030000 sys 0.000000 (best of 100) After: ! visible ! wall 0.000585 comb 0.000000 user 0.000000 sys 0.000000 (best of 4221) The timing above include the computation of obsolete changeset: ! obsolete ! wall 0.000396 comb 0.000000 user 0.000000 sys 0.000000 (best of 6816) So adjusted time give 30ms before versus 0.2ms after. A 150x speedup. 2) mozilla repository with: * 405645 changesets * 4312 hidden changesets (first rev-326004) * 264 visible drafts * obsolete working copy (dynamicblockers), Before: ! visible ! wall 0.168658 comb 0.170000 user 0.170000 sys 0.000000 (best of 48) After ! visible ! wall 0.008612 comb 0.010000 user 0.010000 sys 0.000000 (best of 325) The timing above include the computation of obsolete changeset: ! obsolete ! wall 0.006408 comb 0.010000 user 0.010000 sys 0.000000 (best of 404) So adjusted time give 160ms before versus 2ms after. A 75x speedup.
Sun, 21 May 2017 15:21:46 +0200 hidden: add a function returning ancestors of revs within a domain
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 21 May 2017 15:21:46 +0200] rev 32475
hidden: add a function returning ancestors of revs within a domain See documentation for details. This will be used to improve the hidden computation algorithm. See new changesets for usage.
Fri, 26 May 2017 14:52:54 -0700 tests: hint how to run slow tests when rejecting
Kyle Lippincott <spectral@google.com> [Fri, 26 May 2017 14:52:54 -0700] rev 32474
tests: hint how to run slow tests when rejecting
Fri, 26 May 2017 13:24:07 -0700 zsh_completion: install as _hg not hg
Kyle Lippincott <spectral@google.com> [Fri, 26 May 2017 13:24:07 -0700] rev 32473
zsh_completion: install as _hg not hg The contrib/zsh_completion file itself says to name it _hg. With a name like `hg`, if the user has a line like `autoload ${^fpath}/*(N-.:t)` in their zshrc, it will create a shell function named `hg` that will hide the actual hg command and make hg unusable. Separately from that though, the underscore prefix makes it actually work. The zsh man page states: The convention for autoloaded functions used in completion is that they start with an underscore This does not seem to just be a "convention", though. With the ill-advised line removed from my zshrc and the file named `/usr/local/share/zsh/site-functions/hg` (without the underscore), these completions did not seem to get loaded and the ones from the zsh installation were loaded instead. If I renamed them to be `/usr/local/share/zsh/site-functions/_hg`, however, they were loaded. I manually tested the above statement by starting a new zsh instance with the file in `/usr/local/share/zsh/site-functions` with the following names: - As `hg`, `which _hg_labels` did not show anything - As `_hg`, `which _hg_labels` showed the expected function.
Mon, 20 Mar 2017 17:50:31 -0400 osx: include chg by default
Augie Fackler <augie@google.com> [Mon, 20 Mar 2017 17:50:31 -0400] rev 32472
osx: include chg by default
Fri, 26 May 2017 20:03:05 -0400 osx: override default exclude filter for pkgbuild
Augie Fackler <augie@google.com> [Fri, 26 May 2017 20:03:05 -0400] rev 32471
osx: override default exclude filter for pkgbuild To quote `man 1 pkgbuild`: --filter filter-expression By default, --root will include the entire contents of the given root-path in the package payload, except for any .svn or CVS directories, and any .DS_Store files. You can override these default filters by specifying one or more --filter options. Each filter-expression is an re_format(7) ``extended'' expression: any path in the root which matches any of the given expressions will be excluded from the pack- age payload. (Note that specifying even one --filter inhibits the default filters, so you must respecify the default fil- ters if you still want them to be used.) It turns out the default filter these days *also* includes .git and .hg. Notice how that filter expression is a regular expression? That (presumably unintentionally) prevents a file named "chg" or "_hg" from getting included in the distribution. Many many thanks to spectral@ for trying to include a _hg file which led us to figure this bug out. Bug filed with Apple for this as rdar://problem/32437369, mentioning both the gap in documentation and the wrong defaults.
Fri, 26 May 2017 20:05:59 -0400 osx: update Mac packaging tests for bdiff.so install location change
Augie Fackler <augie@google.com> [Fri, 26 May 2017 20:05:59 -0400] rev 32470
osx: update Mac packaging tests for bdiff.so install location change
Fri, 26 May 2017 19:33:20 -0700 debian: add less as a build dependency stable
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Fri, 26 May 2017 19:33:20 -0700] rev 32469
debian: add less as a build dependency For builds that run on hermetic environments, it's possible that the "less" package is not installed by default, yet it's needed for tests to pass after revision bf5e13e38390 (which sets less as the fallback pager).
Fri, 05 May 2017 18:15:42 +0200 strip: use the 'writenewbundle' function to get bundle on disk
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 05 May 2017 18:15:42 +0200] rev 32468
strip: use the 'writenewbundle' function to get bundle on disk This will ensure the backup bundle use the best available logic (eg: includes relevant caches so that we loose less of them on strip.)
Tue, 23 May 2017 02:23:07 +0200 perfphases: add 'perfphases' command
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 23 May 2017 02:23:07 +0200] rev 32467
perfphases: add 'perfphases' command This commands benchmark the time spend computing the data in a repository.
Tue, 16 May 2017 22:15:42 -0700 match: remove support for excludes from matcher class
Martin von Zweigbergk <martinvonz@google.com> [Tue, 16 May 2017 22:15:42 -0700] rev 32466
match: remove support for excludes from matcher class The support is now provided by differencematcher() and still available via the match() function.
(0) -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 tip