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.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip