Sun, 14 Oct 2018 14:10:38 +0000 py3: fix test-propertycache.py
Mark Thomas <mbthomas@fb.com> [Sun, 14 Oct 2018 14:10:38 +0000] rev 40297
py3: fix test-propertycache.py Differential Revision: https://phab.mercurial-scm.org/D5101
Sun, 14 Oct 2018 14:02:32 +0000 py3: fix test-dirstate-race.t
Mark Thomas <mbthomas@fb.com> [Sun, 14 Oct 2018 14:02:32 +0000] rev 40296
py3: fix test-dirstate-race.t Differential Revision: https://phab.mercurial-scm.org/D5106
Fri, 12 Oct 2018 18:49:11 +0200 help: adding a proper declaration for shortlist/basic commands (API)
Rodrigo Damazio <rdamazio@google.com> [Fri, 12 Oct 2018 18:49:11 +0200] rev 40295
help: adding a proper declaration for shortlist/basic commands (API) We previously used the '^' prefix to indicate that a command should be shown on the short list (shown for just "hg"), but that's a horrible hack, so I'm removing it. Differential Revision: https://phab.mercurial-scm.org/D5069
Fri, 12 Oct 2018 18:06:32 +0200 help: assigning topic categories
Rodrigo Damazio <rdamazio@google.com> [Fri, 12 Oct 2018 18:06:32 +0200] rev 40294
help: assigning topic categories Differential Revision: https://phab.mercurial-scm.org/D5068
Sat, 13 Oct 2018 02:17:41 -0700 help: assigning categories to existing commands
rdamazio@google.com [Sat, 13 Oct 2018 02:17:41 -0700] rev 40293
help: assigning categories to existing commands I'm separating this into its own commit so people can bikeshed over the actual categorization (vs the support for categories). These categories are based on the help implementation we've been using internally at Google, and have had zero complaints. Differential Revision: https://phab.mercurial-scm.org/D5067
Fri, 12 Oct 2018 17:57:36 +0200 help: splitting the topics by category
Rodrigo Damazio <rdamazio@google.com> [Fri, 12 Oct 2018 17:57:36 +0200] rev 40292
help: splitting the topics by category Differential Revision: https://phab.mercurial-scm.org/D5066
Sat, 13 Oct 2018 05:03:50 -0700 help: adding support for command categories
rdamazio@google.com [Sat, 13 Oct 2018 05:03:50 -0700] rev 40291
help: adding support for command categories Differential Revision: https://phab.mercurial-scm.org/D5065
Sun, 14 Oct 2018 13:35:47 +0200 notify: just use email.errors
Yuya Nishihara <yuya@tcha.org> [Sun, 14 Oct 2018 13:35:47 +0200] rev 40290
notify: just use email.errors email.Errors is a proxy object to email.errors on Python 2.
Sat, 06 Oct 2018 21:13:59 +0900 rust-chg: add struct holding information needed to spawn server process
Yuya Nishihara <yuya@tcha.org> [Sat, 06 Oct 2018 21:13:59 +0900] rev 40289
rust-chg: add struct holding information needed to spawn server process The Locator will handle the initialization of the connection. It will spawn server processes as needed.
Sun, 07 Oct 2018 11:32:42 +0900 rust-chg: install logger if $CHGDEBUG is set
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 11:32:42 +0900] rev 40288
rust-chg: install logger if $CHGDEBUG is set This is modeled after the example logger and debugmsg() of chg/util.c. https://docs.rs/log/0.4.5/log/#implementing-a-logger
Sat, 06 Oct 2018 20:07:11 +0900 rust-chg: depend on log and tokio_timer
Yuya Nishihara <yuya@tcha.org> [Sat, 06 Oct 2018 20:07:11 +0900] rev 40287
rust-chg: depend on log and tokio_timer I'll start porting the daemon management functions from chg of C, which will be difficult to debug without some logging facility. AFAIK, the log crate is easy-to-use and widely used. tokio_timer provides sleep() helper to be used while spawning a server process.
Sun, 07 Oct 2018 20:55:51 +0900 rust-chg: suppress panic while writing chg error to stderr
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Oct 2018 20:55:51 +0900] rev 40286
rust-chg: suppress panic while writing chg error to stderr Otherwise "chg >/dev/full 2>&1" would exit with 101. Spotted by test-basic.t.
Sun, 14 Oct 2018 04:37:25 -0400 logcmdutil: add a helpful assertion to catch mistyped templates early
Augie Fackler <augie@google.com> [Sun, 14 Oct 2018 04:37:25 -0400] rev 40285
logcmdutil: add a helpful assertion to catch mistyped templates early This would have made a defect in test-notify.t much easier to figure out. Differential Revision: https://phab.mercurial-scm.org/D5097
Sun, 14 Oct 2018 05:28:01 -0400 notify: adapt to new location of email module's errors
Augie Fackler <augie@google.com> [Sun, 14 Oct 2018 05:28:01 -0400] rev 40284
notify: adapt to new location of email module's errors Differential Revision: https://phab.mercurial-scm.org/D5099
Sun, 14 Oct 2018 04:33:47 -0400 notify: add some b prefixes
Augie Fackler <augie@google.com> [Sun, 14 Oct 2018 04:33:47 -0400] rev 40283
notify: add some b prefixes # skip-blame just b prefixes Differential Revision: https://phab.mercurial-scm.org/D5098
Sun, 14 Oct 2018 09:24:36 +0000 py3: fix test-diff-color.t
Mark Thomas <mbthomas@fb.com> [Sun, 14 Oct 2018 09:24:36 +0000] rev 40282
py3: fix test-diff-color.t Differential Revision: https://phab.mercurial-scm.org/D5095
Sun, 14 Oct 2018 09:07:43 +0000 py3: fix test-revlog.t
Mark Thomas <mbthomas@fb.com> [Sun, 14 Oct 2018 09:07:43 +0000] rev 40281
py3: fix test-revlog.t The mpatchError has a trailing comma on Python 2 but not on Python 3, so use a glob to handle both Python 2 and Python 3. Differential Revision: https://phab.mercurial-scm.org/D5093
Sun, 14 Oct 2018 04:11:35 -0400 fuzz: try *even harder* to prevent Python from looking up usernames
Augie Fackler <augie@google.com> [Sun, 14 Oct 2018 04:11:35 -0400] rev 40280
fuzz: try *even harder* to prevent Python from looking up usernames Differential Revision: https://phab.mercurial-scm.org/D5092
Sun, 14 Oct 2018 03:42:43 -0400 wireproto: fix incorrect function name in docstring
Connor Sheehan <sheehan@mozilla.com> [Sun, 14 Oct 2018 03:42:43 -0400] rev 40279
wireproto: fix incorrect function name in docstring The docstring for `iwireprotocolcommandcacher` references an `onoutputfinished` method. The actual name of the function is `onfinished`. Differential Revision: https://phab.mercurial-scm.org/D5090
Sat, 13 Oct 2018 15:32:52 +0000 py3: fix test-status.t
Mark Thomas <mbthomas@fb.com> [Sat, 13 Oct 2018 15:32:52 +0000] rev 40278
py3: fix test-status.t Differential Revision: https://phab.mercurial-scm.org/D5089
Sun, 14 Oct 2018 07:25:01 +0200 formatter: make debug output prettier
Yuya Nishihara <yuya@tcha.org> [Sun, 14 Oct 2018 07:25:01 +0200] rev 40277
formatter: make debug output prettier "(glob)" won't be needed since pprintgen() can print dict items in stable order.
Sun, 14 Oct 2018 07:23:02 +0200 stringutil: allow to specify initial indent level of pprint()
Yuya Nishihara <yuya@tcha.org> [Sun, 14 Oct 2018 07:23:02 +0200] rev 40276
stringutil: allow to specify initial indent level of pprint() I want to pprint() an inner object, which starts with level=1 indent.
Sun, 14 Oct 2018 07:18:19 +0200 stringutil: make level parameter of pprintgen() 0-origin
Yuya Nishihara <yuya@tcha.org> [Sun, 14 Oct 2018 07:18:19 +0200] rev 40275
stringutil: make level parameter of pprintgen() 0-origin I think this makes more sense in that the level is incremented where nesting goes one more deep.
Sun, 14 Oct 2018 06:51:19 +0200 formatter: use stringutil.pprint() in debug output to drop b''
Yuya Nishihara <yuya@tcha.org> [Sun, 14 Oct 2018 06:51:19 +0200] rev 40274
formatter: use stringutil.pprint() in debug output to drop b''
Thu, 27 Sep 2018 16:56:15 +0200 rust: exposing in parsers module
Georges Racinet <gracinet@anybox.fr> [Thu, 27 Sep 2018 16:56:15 +0200] rev 40273
rust: exposing in parsers module To build with the Rust code, set the HGWITHRUSTEXT environment variable. At this point, it's possible to instantiate and use a rustlazyancestors object from a Python interpreter. The changes in setup.py are obviously a quick hack, just good enough to test/bench without much refactoring. We'd be happy to improve on that with help from the community. Rust bindings crate gets compiled as a static library, which in turn gets linked within 'parsers.so' With respect to the plans at https://www.mercurial-scm.org/wiki/OxidationPlan this would probably qualify as "roll our own FFI". Also, it doesn't quite meet the target of getting rid of C code, since it brings actually more, yet: - the new C code does nothing else than parsing arguments and calling Rust functions. In particular, there's no complex allocation involved. - subsequent changes could rewrite more of revlog.c, this time resulting in an overall decrease of C code and unsafety.
Thu, 27 Sep 2018 16:51:36 +0200 rust: iterator bindings to C code
Georges Racinet <gracinet@anybox.fr> [Thu, 27 Sep 2018 16:51:36 +0200] rev 40272
rust: iterator bindings to C code In this changeset, still made of Rust code only, we expose the Rust iterator for instantiation and consumption from C code. The idea is that both the index and index_get_parents() will be passed from the C extension, hence avoiding a hard link dependency to parsers.so, so that the crate can still be built and tested independently. On the other hand, parsers.so will use the symbols defined in this changeset.
Thu, 27 Sep 2018 17:03:16 +0200 rust: pure Rust lazyancestors iterator
Georges Racinet <gracinet@anybox.fr> [Thu, 27 Sep 2018 17:03:16 +0200] rev 40271
rust: pure Rust lazyancestors iterator This is the first of a patch series aiming to provide an alternative implementation in the Rust programming language of the _lazyancestorsiter from the ancestor module. This iterator has been brought to our attention by the people at Octobus, as a potential good candidate for incremental "oxydation" (rewriting in Rust), because it has shown performance issues lately and it merely deals with ints (revision numbers) obtained by calling the index, whih should be directly callable from Rust code, being itself implemented as a C extension. The idea behind this series is to provide a minimal example of Rust code collaborating with existing C and Python code. To open the way to gradually rewriting more of Mercurial's Python code in Rust, without being forced to pay a large initial cost of rewriting the existing fast core into Rust. This patch does not introduce any bindings to other Mercurial code yet. Instead, it introduces the necessary abstractions to address the problem independently, and unit-test it. Since this is the first use of Rust as a Python module within Mercurial, the hg-core crate gets created within this patch. See its Cargo.toml for more details. Someone with a rustc/cargo installation may chdir into rust/hg-core and run the tests by issuing: cargo test --lib The algorithm is a bit simplified (see details in docstrings), and at its simplest becomes rather trivial, showcasing that Rust has batteries included too: BinaryHeap, the Rust analog of Python's heapq does actually all the work. The implementation can be further optimized and probably be made more idiomatic Rust.
Sat, 13 Oct 2018 23:08:29 -0400 run-tests: restore quoting the python executable for running *.py tests
Matt Harbison <matt_harbison@yahoo.com> [Sat, 13 Oct 2018 23:08:29 -0400] rev 40270
run-tests: restore quoting the python executable for running *.py tests This was accidentally dropped in 8cf459d8b111.
Sat, 13 Oct 2018 19:49:33 -0400 tests: replace `cd ..` with an absolute path in a couple ssh tests
Matt Harbison <matt_harbison@yahoo.com> [Sat, 13 Oct 2018 19:49:33 -0400] rev 40269
tests: replace `cd ..` with an absolute path in a couple ssh tests These tests are broken under py3 on Windows to the point where the `cd ..` was actually escaping into the system wide $TEMP. The subsequent `hg init` created a repo there, and then added a local extension to the hgrc. This breaks every single subsequent test when it tries to `hg init` in its $TESTTMP, and can't load the localwrite.py extension. And since I botched this the first time and replaced the wrong `cd ..`, this just replaces all of them. I've noticed test garbage in $TEMP recently, and maybe this will help. Perhaps `hg init` shouldn't load the config for the local repo, but this is an easy enough workaround for now.
Thu, 04 Oct 2018 00:17:26 -0400 lfs: register the flag processors per repository
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Oct 2018 00:17:26 -0400] rev 40268
lfs: register the flag processors per repository Previously, enabling the extension for any repo in commandserver or hgweb would enable the flags on all repos. Since localrepo.resolverevlogstorevfsoptions() is called so early, the check to see if the extension is enabled on the repo (which hasn't been instantiated yet) is a bit awkward. But I don't see a better way.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip