Fri, 23 Nov 2018 19:32:51 +0100 perf: add a `--timing` argument to `perfhelper-tracecopies`
Boris Feld <boris.feld@octobus.net> [Fri, 23 Nov 2018 19:32:51 +0100] rev 40731
perf: add a `--timing` argument to `perfhelper-tracecopies` The new argument will help picking better pair for benchmarking. See documentation for details.
Sun, 11 Nov 2018 18:08:33 +0900 ui: manage logger instances and event filtering by core ui
Yuya Nishihara <yuya@tcha.org> [Sun, 11 Nov 2018 18:08:33 +0900] rev 40730
ui: manage logger instances and event filtering by core ui The setup code in blackbox needs more tweaks since it has lots of black magics. I'll fix them by follow-up patches. To be clear, the goal of this series is to provide a proper way for command server to install its own logger. I need it to debug in-memory repository cache.
Mon, 12 Nov 2018 21:10:51 +0900 extensions: add "uipopulate" hook, called per instance, not per process
Yuya Nishihara <yuya@tcha.org> [Mon, 12 Nov 2018 21:10:51 +0900] rev 40729
extensions: add "uipopulate" hook, called per instance, not per process In short, this is the "reposetup" function for ui. It allows us to modify ui attributes without extending ui.__class__. Before, the only way to do that was to abuse the config dictionary, which is copied across ui instances. See the next patch for usage example.
Sat, 17 Nov 2018 19:11:45 +0900 hgweb: load globally-enabled extensions explicitly
Yuya Nishihara <yuya@tcha.org> [Sat, 17 Nov 2018 19:11:45 +0900] rev 40728
hgweb: load globally-enabled extensions explicitly Before, extensions were loaded as a side effect of hg.repository() if the hgweb was executed as a CGI/WSGI. I want to make it explicit so that another ui hook can be inserted after extensions.loadall().
Wed, 14 Nov 2018 10:12:43 -0500 tests: sniff for libfuzzer actually being available in test-fuzz-targets.t stable
Augie Fackler <augie@google.com> [Wed, 14 Nov 2018 10:12:43 -0500] rev 40727
tests: sniff for libfuzzer actually being available in test-fuzz-targets.t When I upgraded the FreeBSD buildbot to 11.2 it seems we picked up clang6, but the default clang on FreeBSD doesn't include libfuzzer. I can't find a way to sniff for libfuzzer without running a compile, so here we are. Differential Revision: https://phab.mercurial-scm.org/D5270
Wed, 14 Nov 2018 10:11:37 -0500 tests: sniff for /usr/local/bin/gmake and use it in test-fuzz-targets.t stable
Augie Fackler <augie@google.com> [Wed, 14 Nov 2018 10:11:37 -0500] rev 40726
tests: sniff for /usr/local/bin/gmake and use it in test-fuzz-targets.t This isn't as robust as it probably should be, but for now it'll get the job done on the buildbots. Differential Revision: https://phab.mercurial-scm.org/D5269
Thu, 29 Nov 2018 16:25:37 -0500 tests: stabilize test-inherit-mode.t on FreeBSD and macOS (issue6026) stable
Augie Fackler <augie@google.com> [Thu, 29 Nov 2018 16:25:37 -0500] rev 40725
tests: stabilize test-inherit-mode.t on FreeBSD and macOS (issue6026) Symbolic links are funny permissions-wise, but on the linked issue Yuya has convinced me that we can ignore this permissions issue on macOS (FreeBSD allows setting permissions bits but ignores them) and we'll be in fine shape.
Wed, 28 Nov 2018 12:52:23 -0800 wireprotov2peer: wait for initial object before resolving future stable
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Nov 2018 12:52:23 -0800] rev 40724
wireprotov2peer: wait for initial object before resolving future As part of rolling out wireprotov2 with redirect support, I encountered an edge case with regards to future resolution. Essentially, the initial response frame from the server did not fully decode the initial CBOR object. The frame wasn't marked as EOS. In the previous code, we resolved the future for the request to response.objects(), which mapped to the commandresponse instance which would eventually produce a redirect. Upon receiving subsequent data, the initial CBOR object containing the redirect would be decoded and we'd process the redirect. However, the future would already have been resolved with the initial commandresponse.objects() and the client iterating over the objects wouldn't receive any objects from the redirect because the redirect was populating a different commandresponse instance! This commit changes the logic so we don't resolve futures until the initial CBOR response object is fully decoded or until EOS occurs. In cases where there is an empty or partial frame associated with a redirect, the future will now resolve with the commandresponse containing the proper series of decoded objects.
Wed, 28 Nov 2018 10:37:43 -0800 wireprotov2peer: always return a bool from _processredirect() stable
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 28 Nov 2018 10:37:43 -0800] rev 40723
wireprotov2peer: always return a bool from _processredirect() Without this, we may stop servicing the redirect response if the future has already been resolved. And the future will often be resolved very early, since many consumers iterate the decoded CBOR object stream and expect data to lazily arrive.
Sat, 24 Nov 2018 14:11:02 -0500 tests: disable remotefilelog on Windows
Matt Harbison <matt_harbison@yahoo.com> [Sat, 24 Nov 2018 14:11:02 -0500] rev 40722
tests: disable remotefilelog on Windows I've spent a non trivial amount of time trying to eliminate the test errors, but it's looking like this is pretty dependent on Unix support. For example, there are attempts to delete open files, and uses of threads that report I/O attempts on closed files. (Maybe this is a race condition? Don't we usually use processes as workers on Windows?) In any event, I don't want real new errors elsewhere to be masked by these known problems. For some reason $CACHEDIR is reported as missing in test-remotefilelog-repack.t, but it actually exists in the hgcloneshallow call inside shallowutil.mkstickygroupdir(). By the time the process exits, it's gone. I don't see it being removed by code that calls 'rmdir' or 'remove' in the extension itself.
Thu, 22 Nov 2018 23:48:44 +0100 perf: run 'setup' function during stub run
Boris Feld <boris.feld@octobus.net> [Thu, 22 Nov 2018 23:48:44 +0100] rev 40721
perf: run 'setup' function during stub run The benchmarked function might need the content of the setup to be run in order to function properly.
Fri, 23 Nov 2018 02:08:01 +0100 perf: fallback to subset if ondisk cache is missing in perfbranchmapload
Boris Feld <boris.feld@octobus.net> [Fri, 23 Nov 2018 02:08:01 +0100] rev 40720
perf: fallback to subset if ondisk cache is missing in perfbranchmapload If there is no branchmap on disk for that filter, it means that the cache from some subset's filter is relevant for this one. We look for it instead of aborting. That way it is much simpler to run the command in an automated way. We can now add it to `test-contrib-perf.t`.
Fri, 23 Nov 2018 02:11:11 +0100 perf: prewarm the branchmap in perfbranchmapload
Boris Feld <boris.feld@octobus.net> [Fri, 23 Nov 2018 02:11:11 +0100] rev 40719
perf: prewarm the branchmap in perfbranchmapload It is not very interesting to have the command randomly failing because the branchmap for the tested filter happens to be cold. So we make sure to have a valid up to date branchmap before going further. The data might still be missing from disk if a subset was equivalent. See next changeset for details and fix.
Sun, 25 Nov 2018 22:39:54 +0900 localrepo: correct docstring of filectx()
Yuya Nishihara <yuya@tcha.org> [Sun, 25 Nov 2018 22:39:54 +0900] rev 40718
localrepo: correct docstring of filectx() The same reason as b6c2543e1dd8. It can't be any changeset specifiers but revision number.
Sat, 24 Nov 2018 20:05:55 +0900 annotate: remove dead code to not convert path to relative path
Yuya Nishihara <yuya@tcha.org> [Sat, 24 Nov 2018 20:05:55 +0900] rev 40717
annotate: remove dead code to not convert path to relative path It's annotate. There should be at least one file path specified.
(0) -30000 -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 tip