Wed, 03 Oct 2018 10:46:56 +0200 perf: extract result formatting in its own function
Boris Feld <boris.feld@octobus.net> [Wed, 03 Oct 2018 10:46:56 +0200] rev 40145
perf: extract result formatting in its own function This will make it easier to reuse in another changesets.
Tue, 02 Oct 2018 18:54:06 +0200 perf: extract the timing of a section in a context manager
Boris Feld <boris.feld@octobus.net> [Tue, 02 Oct 2018 18:54:06 +0200] rev 40144
perf: extract the timing of a section in a context manager This makes it easier to reuse it in other (future) part of the code that requires their own time management.
Mon, 01 Oct 2018 17:23:54 +0200 pref: support negative indexing in perfrevlogrevisions
Boris Feld <boris.feld@octobus.net> [Mon, 01 Oct 2018 17:23:54 +0200] rev 40143
pref: support negative indexing in perfrevlogrevisions This is useful to check for a consistent final slice in multiple different repositories.
Mon, 01 Oct 2018 17:37:38 +0200 perf: accept formatter option for perfmanifest
Boris Feld <boris.feld@octobus.net> [Mon, 01 Oct 2018 17:37:38 +0200] rev 40142
perf: accept formatter option for perfmanifest
Mon, 01 Oct 2018 17:53:47 +0200 perf: fix -T json
Boris Feld <boris.feld@octobus.net> [Mon, 01 Oct 2018 17:53:47 +0200] rev 40141
perf: fix -T json The previous code was mixing formatting and data, breaking `-T json` with unexpected data. We fix the issue and add a test to prevent future regression.
Mon, 01 Oct 2018 17:37:53 +0200 formatter: more details on assertion failure
Boris Feld <boris.feld@octobus.net> [Mon, 01 Oct 2018 17:37:53 +0200] rev 40140
formatter: more details on assertion failure This is useful when the assertion fails.
Wed, 10 Oct 2018 23:19:42 -0700 wireprotov2: raise ProgrammingError on unknown action
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 10 Oct 2018 23:19:42 -0700] rev 40139
wireprotov2: raise ProgrammingError on unknown action Suggested by @durin42 in review of D4923. Differential Revision: https://phab.mercurial-scm.org/D4935
Mon, 08 Oct 2018 17:24:28 -0700 wireprotov2: send content encoded frames from server
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 17:24:28 -0700] rev 40138
wireprotov2: send content encoded frames from server Now that we have support for negotiating encodings and configuring an encoder, we can start sending content encoded frames from the server. This commit teaches the wireprotov2 server code to send content encoded frames. On the mozilla-unified repository with zstd enabled peers, this change reduces the total amount of data transferred from server to client drastically: befor: 7,190,995,812 bytes after: 1,605,508,691 bytes Differential Revision: https://phab.mercurial-scm.org/D4927
Mon, 08 Oct 2018 15:19:32 -0700 wireprotov2: raise exception in objects() if future has been resolved
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 15:19:32 -0700] rev 40137
wireprotov2: raise exception in objects() if future has been resolved Differential Revision: https://phab.mercurial-scm.org/D4926
Fri, 05 Oct 2018 23:49:18 +0000 wireprotov2: don't emit empty frames
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 05 Oct 2018 23:49:18 +0000] rev 40136
wireprotov2: don't emit empty frames Staring at logs revealed the presence of empty frames that should have contained payload. Let's stop that from happening. Differential Revision: https://phab.mercurial-scm.org/D4925
Fri, 05 Oct 2018 10:29:36 -0700 wireprotov2: remove functions for creating response frames from bytes
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 05 Oct 2018 10:29:36 -0700] rev 40135
wireprotov2: remove functions for creating response frames from bytes All code in the actual server uses oncommandresponsereadyobjects(). Test code was ported to that method. This resulted in a handful of subtle test changes. Differential Revision: https://phab.mercurial-scm.org/D4924
Fri, 05 Oct 2018 09:23:06 -0700 wireprotov2: handle noop action
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 05 Oct 2018 09:23:06 -0700] rev 40134
wireprotov2: handle noop action This action can be returned from the client reactor. We should handle it. Differential Revision: https://phab.mercurial-scm.org/D4923
Mon, 08 Oct 2018 17:00:16 -0700 wireprotov2: send protocol settings frame from client
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 17:00:16 -0700] rev 40133
wireprotov2: send protocol settings frame from client Now that we have client and server reactor support for protocol settings and encoding frames, we can start to send them out over the wire! This commit teaches the client reactor to send out a protocol settings frame when needed. The httpv2 peer has been taught to gather a list of supported content encoders and to advertise them through the client reactor. Because the client is now sending new frame types by default, this constitutes a compatibility break in the framing protocol. The media type version has been bumped accordingly. This will ensure existing clients won't attempt to send the new frames to old servers not supporting this explicit media type. I'm not bothering with the BC annotation because everything wireprotov2 is highly experimental and nobody should be running a server yet. Differential Revision: https://phab.mercurial-scm.org/D4922
Mon, 08 Oct 2018 17:10:59 -0700 wireprotov2: define and use stream encoders
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 17:10:59 -0700] rev 40132
wireprotov2: define and use stream encoders Now that we have basic support for defining stream encoding, it is time to start doing something with it. We define various classes implementing stream encoders/decoders for the defined encoding profiles. This is relatively straightforward. We teach the inputstream and outputstream classes how to encode, decode, and flush data. We then teach the clientreactor how to filter received data through the inputstream decoder. One of the features of the framing format is that streams can span requests. This is a differentiating feature from say HTTP/2, which associates streams with requests. By allowing streams to span requests, we can reuse compression context data across requests/responses. But in order to do this, we need a mechanism to "flush" the encoder at logical boundaries so that receivers receive all data where it is expected. And a "flush" event is distinct from a "finish" event from the perspective of certain compressors because a "flush" will retain compression context state whereas a "finish" operation will not. This is why encoders have both a flush() and a finish() and each uses specific flushing semantics on the underlying compressor. The added tests verify various behavior of decoders via clientreactor. These tests do test some compression behavior via use of outputstream. But for all intents and purposes, server reactor support for encoding is not yet implemented. Differential Revision: https://phab.mercurial-scm.org/D4921
Thu, 04 Oct 2018 17:39:16 -0700 wireprotov2: establish dedicated classes for input and output streams
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 17:39:16 -0700] rev 40131
wireprotov2: establish dedicated classes for input and output streams Streams are unidirectional. As part of implementing encoding/decoding support, it became clear that it didn't make sense for a generic "stream" class to hold functionality related to both encoding and decoding. So we create new classes to represent the flavor of stream. Differential Revision: https://phab.mercurial-scm.org/D4920
Thu, 04 Oct 2018 17:17:57 -0700 wireprotov2: pass ui into clientreactor and serverreactor
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 17:17:57 -0700] rev 40130
wireprotov2: pass ui into clientreactor and serverreactor This will allow us to use config options to influence compression settings. Differential Revision: https://phab.mercurial-scm.org/D4919
Thu, 04 Oct 2018 16:44:21 -0700 wireprotov2: handle stream encoding settings frames
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 16:44:21 -0700] rev 40129
wireprotov2: handle stream encoding settings frames Like what we just did for the server reactor, we teach the client reactor to handle stream encoding settings frames. The code is very similar. We define a method on the stream class to handle processing the data within the decoded frames. However, it doesn't yet do anything useful. Differential Revision: https://phab.mercurial-scm.org/D4918
Thu, 04 Oct 2018 15:43:21 -0700 wireprotov2: document client reactor actions
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 15:43:21 -0700] rev 40128
wireprotov2: document client reactor actions We should document these so consumers have an easier life. Differential Revision: https://phab.mercurial-scm.org/D4917
Thu, 04 Oct 2018 16:26:45 -0700 wireprotov2: handle sender protocol settings frames
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 16:26:45 -0700] rev 40127
wireprotov2: handle sender protocol settings frames We teach the server reactor to handle the optional sender protocol settings frames, which can only be sent at the beginning of frame exchange. Right now, we simply decode the data and record the sender protocol settings on the server reactor instance: we don't yet do anything meaningful with the data. Differential Revision: https://phab.mercurial-scm.org/D4916
Thu, 04 Oct 2018 14:05:16 -0700 wireprotov2: update stream encoding specification
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 14:05:16 -0700] rev 40126
wireprotov2: update stream encoding specification The encoding of data within streams in the frame-based protocol is not yet defined or implemented. This means that all data in wire protocol version 2 is currently being sent out raw, without compression. That's obviously not ideal. This commit formalizes the beginnings of stream encoding support in the protocol. I suspect we'll change behavior substantially in the future. My goal is to get something landed so we can use compression. We can build out more robust support later. Because the frame type ID changed, this is strictly BC. But existing code wasn't using the frame. I'll bump the framing protocol version later once code is introduced to use the new frame. Differential Revision: https://phab.mercurial-scm.org/D4915
Thu, 04 Oct 2018 15:08:42 -0700 cborutil: cast bytearray to bytes
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 04 Oct 2018 15:08:42 -0700] rev 40125
cborutil: cast bytearray to bytes This code didn't like passing in bytearray instances. Let's cast bytearray to bytes so it works. Differential Revision: https://phab.mercurial-scm.org/D4914
Mon, 08 Oct 2018 17:06:24 -0700 tests: disable zstd in test
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 17:06:24 -0700] rev 40124
tests: disable zstd in test This makes the test pass in pure installs. Differential Revision: https://phab.mercurial-scm.org/D4913
Mon, 08 Oct 2018 17:20:41 -0700 wireprotov2: remove "compression" from capabilities response
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 17:20:41 -0700] rev 40123
wireprotov2: remove "compression" from capabilities response This is not used. And future commits will change how this mechanism works. Let's remove it. As a bonus, this fixes some test failures on pure installs (due to zstd references). Differential Revision: https://phab.mercurial-scm.org/D4912
Mon, 08 Oct 2018 16:27:40 -0700 zstandard: vendor python-zstandard 0.10.1
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 08 Oct 2018 16:27:40 -0700] rev 40122
zstandard: vendor python-zstandard 0.10.1 This was just released. The upstream source distribution from PyPI was extracted. Unwanted files were removed. The clang-format ignore list was updated to reflect the new source of files. setup.py was updated to pass a new argument to python-zstandard's function for returning an Extension instance. Upstream had to change to use relative paths because Python 3.7's packaging doesn't seem to like absolute paths when defining sources, includes, etc. The default relative path calculation is relative to setup_zstd.py which is different from the directory of Mercurial's setup.py. The project contains a vendored copy of zstandard 1.3.6. The old version was 1.3.4. The API should be backwards compatible and nothing in core should need adjusted. However, there is a new "chunker" API that we may find useful in places where we want to emit compressed chunks of a fixed size. There are a pair of bug fixes in 0.10.0 with regards to compressobj() and decompressobj() when block flushing is used. I actually found these bugs when introducing these APIs in Mercurial! But existing Mercurial code is not affected because we don't perform block flushing. # no-check-commit because 3rd party code has different style guidelines Differential Revision: https://phab.mercurial-scm.org/D4911
Tue, 25 Sep 2018 20:55:03 +0900 rust-chg: install signal handlers to forward signals to server
Yuya Nishihara <yuya@tcha.org> [Tue, 25 Sep 2018 20:55:03 +0900] rev 40121
rust-chg: install signal handlers to forward signals to server I use sync::Once as a synchronization primitive because it's quite easy to use, and is good enough to prevent data race in these C functions.
Mon, 24 Sep 2018 22:19:49 +0900 rust-chg: remove SIGCHLD handler which won't work in oxidized chg
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 22:19:49 +0900] rev 40120
rust-chg: remove SIGCHLD handler which won't work in oxidized chg Since pager is managed by the Rust part, the C code doesn't know the pager pid. I could make the Rust part teach the pid to C, but still installing SIGCHLD handler seems horrible idea since we no longer use handcrafted low-level process management functions. Instead, I'm thinking of adding async handler to send SIGPIPE at the exit of the pager.
Mon, 24 Sep 2018 22:04:57 +0900 rust-chg: extract signal handlers from chg/procutil.c
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Sep 2018 22:04:57 +0900] rev 40119
rust-chg: extract signal handlers from chg/procutil.c abortmsgerrno() and debugmsg() are removed, and the public interface instead returns success/error status. Since signal handlers can't propagate errors, the result of kill() is just ignored.
Sun, 07 Oct 2018 23:19:49 +0900 help: document about "version" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 23:19:49 +0900] rev 40118
help: document about "version" template keywords
Sun, 07 Oct 2018 23:14:21 +0900 help: document about "tags" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 23:14:21 +0900] rev 40117
help: document about "tags" template keywords
Sun, 07 Oct 2018 23:12:04 +0900 help: document about "status" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 23:12:04 +0900] rev 40116
help: document about "status" template keywords
Sun, 07 Oct 2018 23:05:00 +0900 help: document about "resolve" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 23:05:00 +0900] rev 40115
help: document about "resolve" template keywords
Sun, 07 Oct 2018 23:00:50 +0900 help: document about "paths" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 23:00:50 +0900] rev 40114
help: document about "paths" template keywords
Sun, 07 Oct 2018 22:56:37 +0900 help: document about "identify" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 22:56:37 +0900] rev 40113
help: document about "identify" template keywords
Sun, 07 Oct 2018 22:50:12 +0900 help: document about "grep" template keywords
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 22:50:12 +0900] rev 40112
help: document about "grep" template keywords
Sun, 07 Oct 2018 17:35:25 +0900 chgserver: catch Abort while parsing early args to shut down cleanly
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 17:35:25 +0900] rev 40111
chgserver: catch Abort while parsing early args to shut down cleanly _loadnewui() calls dispatcher functions, which may raise Abort if unparsable arguments are passed in. The server should catch such errors and translate them to the "exit 255" instruction so the client can finish the IPC session cleanly. Spotted while porting the chg client to Rust.
Fri, 05 Oct 2018 22:08:37 +0900 chg: upgrade client to use "setumask2" command
Yuya Nishihara <yuya@tcha.org> [Fri, 05 Oct 2018 22:08:37 +0900] rev 40110
chg: upgrade client to use "setumask2" command No compatibility code is added to the client side, since it's unlikely for new client to communicate with the old server.
Thu, 04 Oct 2018 23:25:55 +0900 chgserver: add "setumask2" command which uses correct message frame
Yuya Nishihara <yuya@tcha.org> [Thu, 04 Oct 2018 23:25:55 +0900] rev 40109
chgserver: add "setumask2" command which uses correct message frame The first 4 bytes should be a length field, not a value. Spotted while porting chg functions to the Rust one.
Tue, 09 Oct 2018 22:29:10 +0200 packaging: "make deb" no longer fails
muxator <a.mux@inwind.it> [Tue, 09 Oct 2018 22:29:10 +0200] rev 40108
packaging: "make deb" no longer fails Release 4.7 rationalized the layout of the build scripts. Unfortunately, while "make docker-ubuntu-*" and "make docker-debian-*" worked as expected, "make deb" was broken. Before this change "make deb" was failing with the following error: You are not inside a Mercurial repository! Or, after the latest changes: You are inside <fullpath>, which is not the root of a Mercurial repository Moreover, when "make deb" failed, the cleanup routine deleted the wrong directory (contrib/packaging/debian instead of <reporoot>/debian) resulting in a corrupted working copy that needed to be hg revert-ed. After this change the docker targets continue to work, and the deb one is able to finish.
Tue, 09 Oct 2018 22:24:38 +0200 packaging: cleanup() did not read the value of $CLEANUP
muxator <a.mux@inwind.it> [Tue, 09 Oct 2018 22:24:38 +0200] rev 40107
packaging: cleanup() did not read the value of $CLEANUP When the original author put CLEANUP in a conditional statement he was probably willing to use it to control the "if". This change tries to restore that behaviour: the "rm" clause is triggered if and only if CLEANUP is defined and not empty.
Tue, 09 Oct 2018 22:18:35 +0200 packaging: builddeb's cleanup needs to expand PWD, safely
muxator <a.mux@inwind.it> [Tue, 09 Oct 2018 22:18:35 +0200] rev 40106
packaging: builddeb's cleanup needs to expand PWD, safely Single quotes would not expand the variable.
Tue, 09 Oct 2018 22:16:25 +0200 packaging: blindly factor out trap's cleanup function in builddeb
muxator <a.mux@inwind.it> [Tue, 09 Oct 2018 22:16:25 +0200] rev 40105
packaging: blindly factor out trap's cleanup function in builddeb This commit blindly extracts builddeb's trap routine in a dedicated function. While doing so, I think two bugs are exposed, which will be addressed in the next commits: - single quoting around '$CLEANUP' will always evaluate to the literal '$CLEANUP' regardless of the variable's value. The "if" will always be true. - the removal operation will not expand $PWD (and a variable expansion would need double quotes, anyways.
Tue, 09 Oct 2018 21:40:49 +0200 packaging: print full path to the packages when builddeb finishes successfully
muxator <a.mux@inwind.it> [Tue, 09 Oct 2018 21:40:49 +0200] rev 40104
packaging: print full path to the packages when builddeb finishes successfully
Tue, 09 Oct 2018 21:39:39 +0200 packaging: print more specific error messages when builddeb fails
muxator <a.mux@inwind.it> [Tue, 09 Oct 2018 21:39:39 +0200] rev 40103
packaging: print more specific error messages when builddeb fails
Tue, 09 Oct 2018 12:56:11 -0700 cmdutil: sort unresolved paths
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 09 Oct 2018 12:56:11 -0700] rev 40102
cmdutil: sort unresolved paths I noticed that `hg status` was printing unresolved paths in a non-deterministic order. This patch fixes that. I'm not sure if the sorting should be done in merge.mergestate.unresolved() instead. Either way fixes the presentation issue. Differential Revision: https://phab.mercurial-scm.org/D4929
Tue, 09 Oct 2018 07:46:01 +0900 fuzz: report error if Python code raised exception
Yuya Nishihara <yuya@tcha.org> [Tue, 09 Oct 2018 07:46:01 +0900] rev 40101
fuzz: report error if Python code raised exception I think that's what we wanted to do, given the most of the code block is surrounded by try-except. 'lazymanifest(mdata)' is moved to the try block as it can fail.
Tue, 09 Oct 2018 07:42:05 +0900 revlog: explicitly initialize static variables
Yuya Nishihara <yuya@tcha.org> [Tue, 09 Oct 2018 07:42:05 +0900] rev 40100
revlog: explicitly initialize static variables I know .bss section is zero-filled, but explicit initialization should be better as we rely on that.
Mon, 08 Oct 2018 21:53:32 +0200 tests: do not change sys.path, it can break loading cext.parsers
Joerg Sonnenberger <joerg@bec.de> [Mon, 08 Oct 2018 21:53:32 +0200] rev 40099
tests: do not change sys.path, it can break loading cext.parsers When running this tests with run-tests, the prefix would resolve mercurial.cext to the source tree and the attempt to load mercurial.cext.parsers would therefore fail since it doesn't exist in it. With the regular search path from run-tests, it is picked up from the temporary prefix correctly. Differential Revision: https://phab.mercurial-scm.org/D4910
Mon, 08 Oct 2018 21:51:20 +0200 tests: deal with differences in tic from ncurses and NetBSD
Joerg Sonnenberger <joerg@bec.de> [Mon, 08 Oct 2018 21:51:20 +0200] rev 40098
tests: deal with differences in tic from ncurses and NetBSD Differential Revision: https://phab.mercurial-scm.org/D4909
Mon, 08 Oct 2018 20:07:13 +0200 closehead: fix close-head -r listification
Joerg Sonnenberger <joerg@bec.de> [Mon, 08 Oct 2018 20:07:13 +0200] rev 40097
closehead: fix close-head -r listification Differential Revision: https://phab.mercurial-scm.org/D4908
Thu, 23 Aug 2018 12:25:54 +0900 import-checker: use testparseutil.embedded() to centralize detection logic
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 23 Aug 2018 12:25:54 +0900] rev 40096
import-checker: use testparseutil.embedded() to centralize detection logic This patch fixes issues of embedded() in import-checker.py below, too. - overlook (or mis-detect) the end of inline script in doctest style - overlook inline script in doctest style at the end of file (and ignore invalid un-closed heredoc at the end of file, too) - overlook code fragment in styles below - "python <<EOF" (heredoc should be "cat > file <<EOF" style) - "cat > foobar.py << ANYLIMIT" (limit mark should be "EOF") - "cat << EOF > foobar.py" (filename should be placed before limit mark) - "cat >> foobar.py << EOF" (appending is ignored)
Thu, 23 Aug 2018 12:25:54 +0900 tests: use NO_CHECK_EOF as heredoc limit mark to omit checking code fragments
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 23 Aug 2018 12:25:54 +0900] rev 40095
tests: use NO_CHECK_EOF as heredoc limit mark to omit checking code fragments This patch uses NO_CHECK_EOF as heredoc limit mark instead of EOF, in order to avoid checking all python code fragments in test-contrib-check-code.t, because almost all of them has un-recommended implementations intentionally.
Thu, 23 Aug 2018 12:25:54 +0900 contrib: add an utility module to parse test scripts
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 23 Aug 2018 12:25:54 +0900] rev 40094
contrib: add an utility module to parse test scripts This patch centralizes the logic to pick up code fragments embedded in *.t script, in order to: - apply checking with patterns in check-code.py on such embedded code fragments Now, check-code.py completely ignores embedded code fragments. I'll post another patch series to check them. - replace similar code path in contrib/import-checker.py Current import-checker.py has problems below. Fixing each of them is a little difficult, because parsing logic and pattern strings are tightly coupled. - overlook (or mis-detect) the end of inline script in doctest style 8a8dd6e4a97a fixed a part of this issue, but not enough. - it overlooks inline script in doctest style at the end of file (and ignores invalid un-closed heredoc at the end of file, too) - it overlooks code fragment in styles below - "python <<EOF" (heredoc should be "cat > file <<EOF" style) - "cat > foobar.py << ANYLIMIT" (limit mark should be "EOF") - "cat << EOF > foobar.py" (filename should be placed before limit mark) - "cat >> foobar.py << EOF" (appending is ignored) - it is not extensible for other than python code fragments (e.g. shell script, hgrc file, and so on) This new module can detect python code fragments in styles below: - inline script in doctest style (starting by " >>> " line) - python invocation with heredoc script ("python <<EOF") - python script in heredoc style (redirected into ".py" file) As an example of extensibility of new module, this patch also contains implementation to pick up code fragment below. This will be useful to add additional restriction for them, for example. - shell script in heredoc style (redirected into ".sh" file) - hgrc configuration in heredoc style (redirected into hgrc or $HGRCPATH)
Thu, 23 Aug 2018 12:24:41 +0900 tests: use environment variable indirectly
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 23 Aug 2018 12:24:41 +0900] rev 40093
tests: use environment variable indirectly Using environment variable directly in heredoc python code will cause syntax error at checking module importation by import-checker.py strictly, because "$varname" is invalid in Python syntax. "$varname" becomes valid after environment variable substitution by shell at writing text into file. Current import-checker.py overlooks code fragment changed in this patch, because of a restriction below for a line starting code fragment. - filename must be specified before limit mark NG: cat <<EOF > FILE.py OK: cat > FILE.py <<EOF import-checker.py itself is fixed in subsequent patch.
Thu, 23 Aug 2018 12:20:41 +0900 tests: import multiple modules separately
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Thu, 23 Aug 2018 12:20:41 +0900] rev 40092
tests: import multiple modules separately Current import-checker.py overlooks code fragment changed in this patch, because of restrictions below for a line starting code fragment. - filename must be specified before limit mark NG: cat <<EOF > FILE.py OK: cat > FILE.py <<EOF - limit mark must not be quoted NG: cat > FILE.py <<'EOF' OK: cat > FILE.py <<EOF import-checker.py itself is fixed in subsequent patch.
Mon, 08 Oct 2018 11:50:25 -0400 fuzz: allow manifest fuzzer to detect leaks
Augie Fackler <augie@google.com> [Mon, 08 Oct 2018 11:50:25 -0400] rev 40091
fuzz: allow manifest fuzzer to detect leaks Huzzah! Differential Revision: https://phab.mercurial-scm.org/D4907
Mon, 08 Oct 2018 11:47:25 -0400 fuzzers: init Python in LLVMFuzzerInitialize and intentionally leak it
Augie Fackler <augie@google.com> [Mon, 08 Oct 2018 11:47:25 -0400] rev 40090
fuzzers: init Python in LLVMFuzzerInitialize and intentionally leak it This sidesteps leaks (or "leaks", I'm not sure) in CPython, and lets our fuzzer work. Differential Revision: https://phab.mercurial-scm.org/D4906
Mon, 08 Oct 2018 11:42:06 -0400 revlog: if the module is initialized more than once, don't leak nullentry
Augie Fackler <augie@google.com> [Mon, 08 Oct 2018 11:42:06 -0400] rev 40089
revlog: if the module is initialized more than once, don't leak nullentry Caught (annoyingly) by the manifest fuzzer. Differential Revision: https://phab.mercurial-scm.org/D4905
Mon, 01 Oct 2018 14:31:15 -0700 narrow: move remaining narrow-limited dirstate walks to core
Martin von Zweigbergk <martinvonz@google.com> [Mon, 01 Oct 2018 14:31:15 -0700] rev 40088
narrow: move remaining narrow-limited dirstate walks to core In most places we now filter at a higher level (the context object), but there are few places that relied on the dirstate walk to be filtered by the narrowspec. The important cases are those used by `hg add` and `hg addremove`. This patch updates them to pass in a matcher instead of relying on the dirstate to do the filtering. The dirstate filtering is also dropped in narrowdirstate.py. Not always filtering in the dirstate should be useful for a future `hg status --include-outside-narrow` option. These places now end up doing an unrestricted dirstate walk after this patch: * debugfileset * perfwalk * sparse (but restricted to sparse config) * largefiles I'll let anyone who cares about these cases adapt them to work with narrow if necessary. Differential Revision: https://phab.mercurial-scm.org/D4901
Mon, 01 Oct 2018 10:11:00 -0700 narrow: allow repo.narrowmatch(match) to include exact matches from "match"
Martin von Zweigbergk <martinvonz@google.com> [Mon, 01 Oct 2018 10:11:00 -0700] rev 40087
narrow: allow repo.narrowmatch(match) to include exact matches from "match" Differential Revision: https://phab.mercurial-scm.org/D4900
Fri, 28 Sep 2018 22:35:05 -0700 narrow: filter files by narrowspec in ctx.matches()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Sep 2018 22:35:05 -0700] rev 40086
narrow: filter files by narrowspec in ctx.matches() This has no effect yet because 1) for committed changes, ctx.matches() just calls ctx.walk(), which we updated in the previous patch, and 2) for the working copy, the filtering is also done in the overridden dirstate.walk() in narrowdirstate. Differential Revision: https://phab.mercurial-scm.org/D4899
Fri, 28 Sep 2018 17:09:15 -0700 narrow: only walk files within narrowspec also for committed revisions
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Sep 2018 17:09:15 -0700] rev 40085
narrow: only walk files within narrowspec also for committed revisions Narrow has been walking only paths matching the narrowspec when walking the working copy. We have not done the same filtering when walking committed revisions (e.g. "hg files -r "), which seems a little odd. Let's make it consistent. Differential Revision: https://phab.mercurial-scm.org/D4898
Thu, 27 Sep 2018 23:01:26 -0700 status: intersect matcher with narrow matcher instead of filtering afterwards
Martin von Zweigbergk <martinvonz@google.com> [Thu, 27 Sep 2018 23:01:26 -0700] rev 40084
status: intersect matcher with narrow matcher instead of filtering afterwards I seem to have done a very naive move of the code from the narrow extension into core in e411774a2e0f (narrow: move status-filtering to core and to ctx, 2018-08-02). It seems obvious that a better way is to intersect the matchers. Note that this means that when requesting status for the working directory in a narrow repo, we now pass the narrow matcher (possibly intersected with a user-provided matcher) into _buildstatus() and then into dirstate.status() and dirstate.walk(), which will the intersect it again with the narrow matcher. That's functionally fine, but wasteful. I hope to later remove the dirstate wrapping that adds the second layer of matcher intersection. Differential Revision: https://phab.mercurial-scm.org/D4897
Fri, 28 Sep 2018 12:29:21 -0700 localrepo: allow narrowmatch() to accept matcher to intersect with
Martin von Zweigbergk <martinvonz@google.com> [Fri, 28 Sep 2018 12:29:21 -0700] rev 40083
localrepo: allow narrowmatch() to accept matcher to intersect with It's pretty common that we need to intersect a matcher we already have (usually from the user) with the narrow matcher. Let's make repo.narrowmatch() take an optional matcher to intersect with. Differential Revision: https://phab.mercurial-scm.org/D4896
Fri, 05 Oct 2018 01:55:51 +0300 obsolete: fix ValueError when stored note contains ':' char (issue5783)
Zharaskhan Aman <aman.zharaskhan@gmail.com> [Fri, 05 Oct 2018 01:55:51 +0300] rev 40082
obsolete: fix ValueError when stored note contains ':' char (issue5783) The newer version of `amend -n 'Some some'` accepts containing ':' char. The information contained in this note 'Testing::Obstore' gives ValueError, because we are trying to store more than 2 values in key and value. Differential Revision: https://phab.mercurial-scm.org/D4883 Differential Revision: https://phab.mercurial-scm.org/D4882
(0) -30000 -10000 -3000 -1000 -300 -100 -64 +64 +100 +300 +1000 +3000 +10000 tip