Wed, 09 Jan 2019 17:31:36 +0100 rust-cpython: generalised conversion function
Georges Racinet <georges.racinet@octobus.net> [Wed, 09 Jan 2019 17:31:36 +0100] rev 41187
rust-cpython: generalised conversion function Because `hg::ancestors::MissingAncestors` has methods taking some `HashSet<Revision>` besides `impl IntoIterator<Item = Revision>` as parameters we'll need the more generic `rev_pyiter_collect()` function to also build these Differential Revision: https://phab.mercurial-scm.org/D5549
Tue, 08 Jan 2019 14:00:33 +0100 rust-cpython: style consistency leftovers
Georges Racinet <georges.racinet@octobus.net> [Tue, 08 Jan 2019 14:00:33 +0100] rev 41186
rust-cpython: style consistency leftovers In particular, during review of `LazyAncestors` bindings, most `match` statements for error conversion have been replaced by higher level methods of `Result` and most personal insecurity comments have been removed. This makes it more systematic. Differential Revision: https://phab.mercurial-scm.org/D5548
Tue, 08 Jan 2019 13:54:01 +0100 rust-cpython: consistency in use of hg-core constructs
Georges Racinet <georges.racinet@octobus.net> [Tue, 08 Jan 2019 13:54:01 +0100] rev 41185
rust-cpython: consistency in use of hg-core constructs While not everybody likes the `CoreLazy` and `CoreIterator` aliases, it's better not to mix them with direct references. Note: it's quite possible in the future that these would stop being exposed at the top of the `hg` crate Differential Revision: https://phab.mercurial-scm.org/D5547
Sat, 22 Dec 2018 11:38:03 +0100 rust-cpython: rustdoc improvements
Georges Racinet <georges.racinet@octobus.net> [Sat, 22 Dec 2018 11:38:03 +0100] rev 41184
rust-cpython: rustdoc improvements By default, `cargo doc` builds the documentation for public constructs only, so we make public those that can. Since `cindex` is not safe, we keep it private. Unfortunately, the macro syntax of rust-cpython doesn't allow us to document the classes directly, so we resort to do that at the module level. Differential Revision: https://phab.mercurial-scm.org/D5546
Thu, 10 Jan 2019 10:23:22 -0500 fuzz: stop building Python in the Makefile
Augie Fackler <augie@google.com> [Thu, 10 Jan 2019 10:23:22 -0500] rev 41183
fuzz: stop building Python in the Makefile $OUT/sanpy is now built by the build.sh in oss-fuzz, which simplifies the setup here considerably. Differential Revision: https://phab.mercurial-scm.org/D5553
Thu, 10 Jan 2019 23:20:46 +0530 py3: add a test to whitelist caught by buildbot
Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 10 Jan 2019 23:20:46 +0530] rev 41182
py3: add a test to whitelist caught by buildbot Differential Revision: https://phab.mercurial-scm.org/D5555
Thu, 10 Jan 2019 16:36:55 -0800 tests: de-flake test-narrow-share.t by making dirstate predictable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Jan 2019 16:36:55 -0800] rev 41181
tests: de-flake test-narrow-share.t by making dirstate predictable test-narrow-share.t was sometimes (~0.5% on my machine) failing like this: @@ -61,7 +61,7 @@ A d3/g $ hg -R main debugdirstate --no-dates n 644 2 set d1/f - n 644 2 unset d3/f + n 644 2 set d3/f a 0 -1 unset d3/g n 644 2 set d5/f n 644 2 set d7/f The timestamp for d3/f would get set if it was determined at some point that it was clean. That check is usually done when the user runs `hg st`. We don't do that before the failure in the test case, but it happens at the end of the `hg clone` call. So if the file system's time happens to roll over after the clone's working copy has been written, but before its (final) dirstate has been written, we can end up with a set timestamp there. This patch makes it consistent by sleeping for 2 seconds so the timestamp gets reliably set. Differential Revision: https://phab.mercurial-scm.org/D5568
Wed, 09 Jan 2019 16:02:05 -0500 convert: don't drop commits that are empty in the source when using --filemap
Matt Harbison <matt_harbison@yahoo.com> [Wed, 09 Jan 2019 16:02:05 -0500] rev 41180
convert: don't drop commits that are empty in the source when using --filemap I ran into this when using `hg lfconvert --to-normal` (which uses the filemap class internally), and saw that commits with nothing but a branch change were dropped. We could put in an option that only lfconvert uses internally. But silently dropping anything other than a commit where all changes were excluded seems unintended. For example, there's a message in mercurial_sink.putcommit() if it drops an empty commit. (And the reason that isn't kicking in here is because lfconvert isn't passing --filemap, so the self.filemapmode conditional there is always False.) The naive change of `return not files` broke test-convert-filemap.t, so this is a little more elaborate than needed for converting from largefiles.
Wed, 09 Jan 2019 14:33:06 -0500 convert: add missing numcommits() override to hg sources
Matt Harbison <matt_harbison@yahoo.com> [Wed, 09 Jan 2019 14:33:06 -0500] rev 41179
convert: add missing numcommits() override to hg sources Otherwise, the progressbar in converter.walktree() gets None as its total during the initial scan. (Though that seems harmless, and there are other foreign vcs sources without this.)
Thu, 10 Jan 2019 14:32:36 -0800 testrunner: make `-j100 --runs-per-test=100 test-foo.t` use 100 jobs
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Jan 2019 14:32:36 -0800] rev 41178
testrunner: make `-j100 --runs-per-test=100 test-foo.t` use 100 jobs It would use only 1 job since 1039404c5e1d (run-tests: print number of tests and parallel process count, 2018-10-13), but I'm pretty sure that was unintentional. Differential Revision: https://phab.mercurial-scm.org/D5557
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip