Wed, 19 Jun 2019 05:37:33 +0200 run-tests: stop matching line for missing feature stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 19 Jun 2019 05:37:33 +0200] rev 42505
run-tests: stop matching line for missing feature Before this change, the following unified test input would silently pass $ echo foo foo (false !) After this change, the "foo" output is properly detected as unexpected. The output of an handful of test had to be updated from broken conditional (that ended up working by chance).
Wed, 19 Jun 2019 10:19:32 -0700 log: pass getcopies() function instead of getrenamed() to displayer (API)
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 10:19:32 -0700] rev 42504
log: pass getcopies() function instead of getrenamed() to displayer (API) This reduces the duplication between the two displayer functions (and between them and scmutil.getcopiesfn()). It's still more code than two patches ago, but there's less duplication. Differential Revision: https://phab.mercurial-scm.org/D6546
Wed, 19 Jun 2019 09:59:45 -0700 copies: create helper for getting all copies for changeset
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 09:59:45 -0700] rev 42503
copies: create helper for getting all copies for changeset There are a few places where we get all the copies for a changeset (at least the {file_copies} template and in two places in `hg log --copies` code). These places currently call scmutil.getrenamedfn() to get a caching "getrenamed" function. They all use it in a similar way. We will be able to reuse more code by having a function for getting all the copies for a changeset. This patch introduces such a function. It uses it in the {file_copies} template to show that it works. It relies on the existing scmutil.getrenamedfn() for caching in the filelog-centric case. Differential Revision: https://phab.mercurial-scm.org/D6545
Tue, 18 Jun 2019 23:19:24 -0700 logcmdutil: also check for copies in null revision and working copy
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jun 2019 23:19:24 -0700] rev 42502
logcmdutil: also check for copies in null revision and working copy It's safe (and fast) to look for copies in the null revision, and it's incorrect not to look for them in the working copy, so let's look in both places. Differential Revision: https://phab.mercurial-scm.org/D6544
Tue, 18 Jun 2019 23:23:30 -0700 tests: demonstrate missing copy information in working copy with graphlog
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jun 2019 23:23:30 -0700] rev 42501
tests: demonstrate missing copy information in working copy with graphlog Differential Revision: https://phab.mercurial-scm.org/D6543
Wed, 19 Jun 2019 10:33:13 -0700 remotefilelog: handle copies in changesets in getrenamedfn() override
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 10:33:13 -0700] rev 42500
remotefilelog: handle copies in changesets in getrenamedfn() override E.g. the {file_copies} template keyword didn't work with copies in changesets before this patch because remotefilelog overrides the getrenamedfn() and didn't handle the changeset-centric case. Differential Revision: https://phab.mercurial-scm.org/D6542
Wed, 19 Jun 2019 11:12:06 -0700 remotefilelog: check if RFL is enabled in getrenamedfn() override
Martin von Zweigbergk <martinvonz@google.com> [Wed, 19 Jun 2019 11:12:06 -0700] rev 42499
remotefilelog: check if RFL is enabled in getrenamedfn() override In 8a0e03f7baf4 (remotefilelog: move most setup from onetimesetup() to uisetup(), 2019-05-01), I said: All the wrappers moved in this patch check if remotefilelog is enabled before they change behavior, so it's safe to always wrap. That was clearly a lie, because getrenamedfn() didn't. That made e.g. `hg log -T {file_copies}` unbearably slow. This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D6541
Tue, 18 Jun 2019 08:55:23 -0700 relnotes: document template support for `hg root`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 18 Jun 2019 08:55:23 -0700] rev 42498
relnotes: document template support for `hg root` Differential Revision: https://phab.mercurial-scm.org/D6540
Tue, 18 Jun 2019 09:57:06 -0400 remotefilelog: tell runbgcommand to not block on child process startup
Augie Fackler <augie@google.com> [Tue, 18 Jun 2019 09:57:06 -0400] rev 42497
remotefilelog: tell runbgcommand to not block on child process startup These two invocations will always find a binary because they're re-running hg. As a result, we can skip waiting for the subprocess to start running and save a little bit of wall-time. Differential Revision: https://phab.mercurial-scm.org/D6539
Tue, 18 Jun 2019 09:43:27 -0400 procutil: allow callers of runbgcommand to assume the process starts
Augie Fackler <augie@google.com> [Tue, 18 Jun 2019 09:43:27 -0400] rev 42496
procutil: allow callers of runbgcommand to assume the process starts Experimentally starting the subprocess can take as much as 40ms, and for some of our use cases that's frivolous: we know the binary will start, and if it doesn't we'd only ever ignore it and continue anyway. This lets those use cases be faster. Differential Revision: https://phab.mercurial-scm.org/D6537
Tue, 18 Jun 2019 09:58:01 -0400 shallowrepo: remove backwards compat code that predates in-tree remotefilelog
Augie Fackler <augie@google.com> [Tue, 18 Jun 2019 09:58:01 -0400] rev 42495
shallowrepo: remove backwards compat code that predates in-tree remotefilelog Differential Revision: https://phab.mercurial-scm.org/D6538
Tue, 16 Apr 2019 02:53:28 +0530 commit: make the error message more specific while aborting branch closing
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Apr 2019 02:53:28 +0530] rev 42494
commit: make the error message more specific while aborting branch closing Differential Revision: https://phab.mercurial-scm.org/D6493
Tue, 16 Apr 2019 02:33:54 +0530 commit: add a check if it is trying to close an already closed branch head
Sushil khanchi <sushilkhanchi97@gmail.com> [Tue, 16 Apr 2019 02:33:54 +0530] rev 42493
commit: add a check if it is trying to close an already closed branch head It would check if the revision we are going to close is already a closed branch head and print the error message accordingly. Differential Revision: https://phab.mercurial-scm.org/D6491
Mon, 17 Jun 2019 10:53:00 -0700 strip: move checksubstate() to mq (its only caller)
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:53:00 -0700] rev 42492
strip: move checksubstate() to mq (its only caller) Differential Revision: https://phab.mercurial-scm.org/D6536
Mon, 17 Jun 2019 10:19:41 -0700 strip: use bailifchanged() instead of reimplementing it
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:19:41 -0700] rev 42491
strip: use bailifchanged() instead of reimplementing it This also means that we get the standard error messages (see changed test cases). Differential Revision: https://phab.mercurial-scm.org/D6535
Mon, 17 Jun 2019 10:40:24 -0700 strip: remove unused excsuffix argument from checklocalchanges()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:40:24 -0700] rev 42490
strip: remove unused excsuffix argument from checklocalchanges() It was only used by mq, and mq now has its own copy of the function. Differential Revision: https://phab.mercurial-scm.org/D6534
Mon, 17 Jun 2019 10:38:50 -0700 mq: remove dependency on strip's checklocalchanges()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Jun 2019 10:38:50 -0700] rev 42489
mq: remove dependency on strip's checklocalchanges() Some of the functionality in strip.checklocalchanges() was only used by mq, so let's move it to mq so we can clean up strip. Differential Revision: https://phab.mercurial-scm.org/D6533
Thu, 02 May 2019 23:39:33 -0700 copies: avoid calling matcher if matcher.always()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 02 May 2019 23:39:33 -0700] rev 42488
copies: avoid calling matcher if matcher.always() When storing copy information in the changesets (experimental.copies.read-from=changeset-only), this patch speeds up hg debugpathcopies FENNEC_58_0_2_BUILD1 FIREFOX_59_0b8_BUILD2 from 5.9s to 4.7s. At the start of this series (b162229e), that command took 18min. Differential Revision: https://phab.mercurial-scm.org/D6422
Thu, 18 Apr 2019 21:21:44 -0700 copies: avoid unnecessary copying of copy dict
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 21:21:44 -0700] rev 42487
copies: avoid unnecessary copying of copy dict When storing copy information in the changesets, this patch speeds up hg debugpathcopies FENNEC_58_0_2_BUILD1 FIREFOX_59_0b8_BUILD2 from 11s to 5.9s. That command takes 6.2s when storing copy information in filelogs. Differential Revision: https://phab.mercurial-scm.org/D6421
Thu, 18 Apr 2019 21:22:14 -0700 copies: don't filter out copy targets created on other side of merge commit
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 21:22:14 -0700] rev 42486
copies: don't filter out copy targets created on other side of merge commit If file X is copied to Y on one side of merge and the other side creates Y (no copy), we would not mark that as copy. In the changeset-centric pathcopies() version, that was done by checking if the copy target existed on the other branch. Even though merge commits are pretty uncommon, it still turned out to be too expensive to load the manifest of the parents of merge commits. In a repo of mozilla-unified converted to storing copies in changesets, about 2m30s of `hg debugpathcopies FIREFOX_BETA_59_END FIREFOX_BETA_60_BASE` is spent on this check of merge commits. I tried to think of a way of storing more information in the changesets in order to cheaply detect these cases, but I couldn't think of a solution. So this patch simply removes those checks. For reference, these extra copies are reported from the aforementioned command after this patch: browser/base/content/sanitize.js -> browser/modules/Sanitizer.jsm testing/mozbase/mozprocess/tests/process_normal_finish_python.ini -> testing/mozbase/mozprocess/tests/process_normal_finish.ini testing/mozbase/mozprocess/tests/process_waittimeout_python.ini -> testing/mozbase/mozprocess/tests/process_waittimeout.ini testing/mozbase/mozprocess/tests/process_waittimeout_10s_python.ini -> testing/mozbase/mozprocess/tests/process_waittimeout_10s.ini Since these copies were created on one side of some merge, it still seems reasonable to include them, so I'm not even sure it's worse than filelog pathcopies(), just different. Differential Revision: https://phab.mercurial-scm.org/D6420
Thu, 18 Apr 2019 00:40:53 -0700 copies: do full filtering at end of _changesetforwardcopies()
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 00:40:53 -0700] rev 42485
copies: do full filtering at end of _changesetforwardcopies() As mentioned earlier, pathcopies() is very slow when copies are stored in the changeset. Most of the cost comes from calling _chain() for every changeset, which is slow because it needs to read manifests. It needs to read manifests to be able to filter out copies that are were created in one commit and then deleted. (It also filters out copies that were created from a file that didn't exist in the starting revision, but that's a fixed revision across calls to _chain(), so it's much cheaper.) This patch changes from _chainandfilter() to just _chain() in the main loop in _changesetforwardcopies(). It instead removes copies that have subsequently been removed by using ctx.filesremoved(). We thus rely on that to be fast. It timed this command in mozilla-unified: hg debugpathcopies FIREFOX_59_0b3_BUILD2 FIREFOX_BETA_59_END It took 18s before and 1.1s after. It's still faster when copy information is stored in filelogs: 0.70s. It also still gets slow when there are merge commits involved, because we read manifests there too. We'll deal with that later. Differential Revision: https://phab.mercurial-scm.org/D6419
Sat, 15 Jun 2019 10:58:53 +0900 rust-filepatterns: add comment about Windows path handling
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Jun 2019 10:58:53 +0900] rev 42484
rust-filepatterns: add comment about Windows path handling As I replied to the Phabricator message, this is wrong. And I even suspect it wouldn't compile because of multiple type mismatches. I think, in Rust where type system is rock solid, we can live with UTF-8 strings except for the bottom storage layer and the top UI/command layer. We'll still have to get around undecodable characters not to be lost, but I think it's okay to drop such filenames from match result if they don't match in UTF-8 world, not in Latin-1 world.
Sat, 15 Jun 2019 10:35:53 +0900 rust-filepatterns: silence warning of non_upper_case_globals
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Jun 2019 10:35:53 +0900] rev 42483
rust-filepatterns: silence warning of non_upper_case_globals
Sat, 15 Jun 2019 10:35:03 +0900 rust: update Cargo.lock to include @generated comment
Yuya Nishihara <yuya@tcha.org> [Sat, 15 Jun 2019 10:35:03 +0900] rev 42482
rust: update Cargo.lock to include @generated comment cargo 1.34.0 of Debian sid inserts this comment, and I'm tired of reverting the change every time I do make local. https://github.com/rust-lang/cargo/commit/bd0e4a08471b8bc7957829b4fd294b8985d4fa2d
Mon, 17 Jun 2019 13:21:41 -0400 merge with stable
Augie Fackler <augie@google.com> [Mon, 17 Jun 2019 13:21:41 -0400] rev 42481
merge with stable
Sun, 16 Jun 2019 12:31:07 +0900 cborutil: fix streamencode() to handle subtypes stable
Yuya Nishihara <yuya@tcha.org> [Sun, 16 Jun 2019 12:31:07 +0900] rev 42480
cborutil: fix streamencode() to handle subtypes Otherwise the template filter 'cbor' could crash because of bytes subclass: ValueError: do not know how to encode <class 'mercurial.encoding.safelocalstr'>
Fri, 14 Jun 2019 00:30:33 -0400 lfs: correct an error in the TODO file
Matt Harbison <matt_harbison@yahoo.com> [Fri, 14 Jun 2019 00:30:33 -0400] rev 42479
lfs: correct an error in the TODO file
Thu, 04 Oct 2018 00:57:11 -0400 cat: don't prefetch files unless the output requires it
Matt Harbison <matt_harbison@yahoo.com> [Thu, 04 Oct 2018 00:57:11 -0400] rev 42478
cat: don't prefetch files unless the output requires it It's a waste to cache lfs blobs when cat'ing the raw data at best, but a hassle debugging when the blob is missing. I'm not sure if there are other commands that have '{data}' for output, and if there's a general way to prefetch on that keyword. It's interesting that the verbose output seems to leak into the JSON output, but that seems like an existing bug.
Wed, 12 Jun 2019 19:01:49 -0400 tracing: add support for emitting counters
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 19:01:49 -0400] rev 42477
tracing: add support for emitting counters Differential Revision: https://phab.mercurial-scm.org/D6526
Wed, 12 Jun 2019 19:01:37 -0400 tracing: extract tracing-active logic to separate function
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 19:01:37 -0400] rev 42476
tracing: extract tracing-active logic to separate function I'm about to add support for counters, and want to avoid duplicating this logic. Differential Revision: https://phab.mercurial-scm.org/D6525
Wed, 12 Jun 2019 19:00:46 -0400 catapipe: add support for COUNTER events
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 19:00:46 -0400] rev 42475
catapipe: add support for COUNTER events Differential Revision: https://phab.mercurial-scm.org/D6524
Wed, 12 Jun 2019 16:08:21 -0400 demandimport: add tracing coverage for Python 3
Augie Fackler <augie@google.com> [Wed, 12 Jun 2019 16:08:21 -0400] rev 42474
demandimport: add tracing coverage for Python 3 This makes things feel a little less mysterious when modules are being imported. Differential Revision: https://phab.mercurial-scm.org/D6523
Fri, 14 Jun 2019 10:21:47 -0700 export: don't prefetch *all* files in manifest
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Jun 2019 10:21:47 -0700] rev 42473
export: don't prefetch *all* files in manifest `hg export` only shows changed files, not all files, but we still prefetched all files in cmdutil.export(). The same is true for the other commands calling cmdutil.exportfile(). That meant that `hg export` with remotefilelog (or lfs, I assume) could take much longer than expected because it would download all the files in the repo. Differential Revision: https://phab.mercurial-scm.org/D6532
Fri, 14 Jun 2019 13:50:06 -0700 remotefilelog: remove obsolete filtering of treemanifest directories
Martin von Zweigbergk <martinvonz@google.com> [Fri, 14 Jun 2019 13:50:06 -0700] rev 42472
remotefilelog: remove obsolete filtering of treemanifest directories I think this has been obsolete since 2cf18f46a1ce (narrow: only walk files within narrowspec also for committed revisions, 2018-09-28). Differential Revision: https://phab.mercurial-scm.org/D6531
Fri, 14 Jun 2019 18:27:50 +0300 py3: add test-dirstate-race2.t to list of passing tests
Pulkit Goyal <7895pulkit@gmail.com> [Fri, 14 Jun 2019 18:27:50 +0300] rev 42471
py3: add test-dirstate-race2.t to list of passing tests This test was added new recently. The py3 buildbot found that it passes, so let's add it to the list of passing tests. Differential Revision: https://phab.mercurial-scm.org/D6530
Fri, 14 Jun 2019 18:25:14 +0530 strip: during merge allow strip only when -f is used
Taapas Agrawal <taapas2897@gmail.com> [Fri, 14 Jun 2019 18:25:14 +0530] rev 42470
strip: during merge allow strip only when -f is used This ensures to abort strip to `hg strip` when we have a merge in progress and allow it only when a `--force` flag is used. Differential Revision: https://phab.mercurial-scm.org/D6529
Fri, 26 Apr 2019 00:48:12 +0200 deltas: set estimated compression upper bound to "3x" instead of "10x"
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 26 Apr 2019 00:48:12 +0200] rev 42469
deltas: set estimated compression upper bound to "3x" instead of "10x" In pratice, we very rarely observer compression better than "3x" on manifest deltas. Having a more aggressive estimate significantly helps our pathological use case on a private repository. Here are a comparison of timings using different upper bound. Estimated compression | ø | ×10 | ×5 | ×3 | timing | 14.11 | 2.61 | 1.96 | 1.53 | We also tested the impact of this series on an array of public repositories. This shown no impact in either size nor timing. Full data set below for those interested. Size ---- Regarding size, not significant impact have been noticed on neither public nor private repositories. Here are the number we gathered on public repositories: zlib/upperbound | no | 10x | 5x | 3x mercurial | 5 875 730 | 5 875 730 | 5 875 730 | 5 875 730 pypy | 27 782 913 | 27 782 913 | 27 782 913 | 27 782 913 netbeans | 159 161 207 | 159 161 207 | 159 161 207 | 159 959 879 (+0.5%) mozilla-central | 323 841 642 | 323 841 642 | 323 841 642 | 319 867 519 (-2.5%) mozilla-try | 746 649 123 | 746 649 123 | 746 649 123 | 741 155 568 (-0.7%) private-repo | 1 485 287 294 | 1 485 287 294 | 1 485 287 294 | 1 409 248 382 (-5.1%) zstd/upperbound | no | 10x | 5x | 3x mercurial | 5 895 206 | 5 895 206 | 5 895 206 | 5 895 206 pypy | 28 689 230 | 28 689 230 | 28 689 230 | 28 689 230 netbeans | 157 636 387 | 157 636 387 | 157 636 387 | 159 692 678 (+1.3%) mozilla-central | 317 650 281 | 317 650 281 | 317 650 281 | 319 613 603 (+0.6%) mozilla-try | 737 555 275 | 737 555 275 | 737 555 275 | 738 079 473 (+0.1%) private-repo | 1 352 362 982 | 1 352 362 982 | 1 346 961 880 | 1 361 327 384 (+0.7%) Speed ------ Timing gathered using `hg perfrevlogwrite -m`. Value are in seconds. mercurial zlib | no | 10x | 5x | 3x | total | 65.551783 | 65.388887 | 65.260658 | 65.321199 | max | 0.034544 | 0.034571 | 0.034659 | 0.034521 | 99.99% | 0.034544 | 0.034571 | 0.034659 | 0.034521 | zstd | no | 10x | 5x | 3x | total | 49.118449 | 49.054062 | 48.753588 | 48.740230 | max | 0.009338 | 0.009239 | 0.009202 | 0.009178 | 99.99% | 0.007618 | 0.007639 | 0.007626 | 0.007621 | pypy zlib | no | 10x | 5x | 3x | total | 560.865984 | 558.983817 | 559.083815 | 559.349152 | max | 0.219614 | 0.215922 | 0.218112 | 0.218107 | 99.99% | 0.219614 | 0.215922 | 0.218112 | 0.218107 | zstd | no | 10x | 5x | 3x | total | 349.393280 | 347.395819 | 347.185407 | 345.643985 | max | 0.084143 | 0.083536 | 0.081834 | 0.082178 | 99.99% | 0.039445 | 0.039639 | 0.039612 | 0.039175 | netbeans zlib | no | 10x | 5x | 3x | total | 33103.327727 | 33314.932260 | 33211.745233 | 33345.891778 | max | 2.666852 | 2.672059 | 2.662453 | 2.662936 | 99.99% | 2.058772 | 2.070429 | 2.069569 | 2.064653 | zstd | no | 10x | 5x | 3x | total | 20112.102708 | 20095.879719 | 20083.390300 | 20123.221859 | max | 2.063482 | 2.062851 | 2.065229 | 2.060147 | 99.99% | 1.146647 | 1.143794 | 1.142933 | 1.146529 | mozilla zlib | no | 10x | 5x | 3x | total | 41374.102138 | 41418.816773 | 41381.956370 | 41334.280732 | max | 3.383474 | 3.387400 | 3.405711 | 3.387316 | 99.99% | 1.006755 | 1.005954 | 1.007700 | 1.007373 | zstd | no | 10x | 5x | 3x | total | 24689.691520 | 24643.939662 | 24664.630027 | 24664.512714 | max | 1.460822 | 1.449640 | 1.439747 | 1.465304 | 99.99% | 0.527111 | 0.527377 | 0.527807 | 0.527226 |
Mon, 21 Jan 2019 22:46:31 +0100 deltas: skip if projected compressed size is bigger than previous snapshot
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:46:31 +0100] rev 42468
deltas: skip if projected compressed size is bigger than previous snapshot If we have a delta, we check constraints against a lower bound estimate of the resulting compressed delta. We then checks this projected size against the `size(snapshotⁿ) > size(snapshotⁿ⁺¹)` constraint. This allows to exclude potential base candidates before doing any expensive computation. This only apply to the intermediate-snapshot case since this constraint only apply to them. For some pathological cases of a private repository this step provide a further performance boost (timing from `hg perfrevlogwrite`): before: 3.010646 seconds after: 2.609307 seconds
Mon, 21 Jan 2019 22:46:18 +0100 deltas: skip if projected compressed size does not match text size constraint
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:46:18 +0100] rev 42467
deltas: skip if projected compressed size does not match text size constraint If we have a delta, we check constraints against a lower bound estimate of the resulting compressed delta. We then checks this projected size against the ½ⁿ size constraints. This allows to exclude potential base candidates before doing any expensive computation. This only apply to the intermediate-snapshot case since this constraint only apply to them. For some pathological cases of a private repository this step provide a further performance boost (timing from `hg perfrevlogwrite`): before: 3.145906 seconds after: 3.010646 seconds
Mon, 21 Jan 2019 22:37:30 +0100 deltas: accept and skip None return for delta info
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:37:30 +0100] rev 42466
deltas: accept and skip None return for delta info They are some extra computation that will shortcut the delta compression if the delta seems hopeless, returning None.
Mon, 21 Jan 2019 22:36:16 +0100 delta: move some delta chain related computation earlier in deltainfo
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 21 Jan 2019 22:36:16 +0100] rev 42465
delta: move some delta chain related computation earlier in deltainfo They are some more optimization change that will make use of this in the function. So we retrieve the data earlier.
Thu, 25 Apr 2019 22:50:33 +0200 deltas: skip if projected delta size is bigger than previous snapshot
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Thu, 25 Apr 2019 22:50:33 +0200] rev 42464
deltas: skip if projected delta size is bigger than previous snapshot Before computing any delta, we get a basic estimation of the delta size we can expect and the resulted compressed value. We then checks this projected size against the `size(snapshotⁿ) > size(snapshotⁿ⁺¹)` constraint. This allows to exclude potential base candidates before doing any expensive computation. This only apply to the intermediate-snapshot case since this constraint only apply to them. For some pathological cases of a private repository this step provide a significant performance boost (timing from `hg perfrevlogwrite`): before: 14.115908 seconds after: 3.145906 seconds
Thu, 25 Apr 2019 22:30:14 +0200 deltas: skip if projected delta size does not match text size constraint
Valentin Gatien-Baron <vgatien-baron@janestreet.com>, Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 25 Apr 2019 22:30:14 +0200] rev 42463
deltas: skip if projected delta size does not match text size constraint Before computing any delta, we get a basic estimation of the delta size we can expect and the resulted compressed value. We then checks this projected size against the ½ⁿ size constraints. This allows to exclude potential base candidates before doing any expensive computation. This only apply to the intermediate-snapshot case since this constraint only apply to them. In practice we only perform this new checks for the manifestlog. Manifest log combine two property: it is likely to have delta chain issue and its diffing/compression is fairly predictable. The initial author of this changeset is Valentin Gatien-Baron providing the initial idea and initial testing, Pierre-Yves David later consolidated the code in the right location and run more extensive testing.
Fri, 26 Apr 2019 00:28:22 +0200 revlog: add the option to track the expected compression upper bound
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 26 Apr 2019 00:28:22 +0200] rev 42462
revlog: add the option to track the expected compression upper bound There are various optimization we can do if we can estimate the size of delta before actually spending CPU compressing them. So we add a attributed dedicated to tracking that. We only use it on Manifest because (1) it structure is quite stable across all Mercurial repository so its compression ratio is fairly universal. This is the revlog with most extreme delta (cf the sparse-revlog optimization). This will be put to use in later changesets. Right now the compression upper bound is set to 10. This is a fairly conservative value (observed value is more around 3), but I prefer to be safe while introducing the optimization principles. We can tune the optimization threshold later.
Wed, 12 Jun 2019 17:30:24 +0100 perf: clarify some of the custom behavior of `perfrevlogwrite`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2019 17:30:24 +0100] rev 42461
perf: clarify some of the custom behavior of `perfrevlogwrite` This reduce the chance of developers being surprised by special cases.
Wed, 12 Jun 2019 16:56:41 +0100 perf: fix perfrevlogwrite --count documentation
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 12 Jun 2019 16:56:41 +0100] rev 42460
perf: fix perfrevlogwrite --count documentation The help text was copy pasted from the previous option.
Fri, 17 May 2019 00:17:43 +0200 rust: switched to 'cargo rustc' in setup.py
Georges Racinet <georges.racinet@octobus.net> [Fri, 17 May 2019 00:17:43 +0200] rev 42459
rust: switched to 'cargo rustc' in setup.py This is more flexible in the passing of additional flags, also what setuptools_rust does, giving less uncertainty about non-Linux platforms.
Fri, 14 Jun 2019 11:18:06 +0100 rust-cpython: fix build for MacOSX
Georges Racinet <georges.racinet@octobus.net> [Fri, 14 Jun 2019 11:18:06 +0100] rev 42458
rust-cpython: fix build for MacOSX MacOSX needs special link flags. Quoting the README of rust-cpython: create a `.cargo/config` with the following content: ``` [target.x86_64-apple-darwin] rustflags = [ "-C", "link-arg=-undefined", "-C", "link-arg=dynamic_lookup", ] ``` This is tested with Python 2.7 (Anaconda install) and Python 3 (Homebrew install)
Fri, 14 Jun 2019 10:57:07 +0100 rust-cpython: management of shared libray suffix
Georges Racinet <georges.racinet@octobus.net> [Fri, 14 Jun 2019 10:57:07 +0100] rev 42457
rust-cpython: management of shared libray suffix Before this changeset, the shared library objects suffixes were both (rustc output and Python input) hardcoded to '.so', which is wrong for Python3 and non Linux targets.
Mon, 27 May 2019 16:55:46 -0400 merge: fix race that could cause wrong size in dirstate
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 27 May 2019 16:55:46 -0400] rev 42456
merge: fix race that could cause wrong size in dirstate The problem is that hg merge/update/etc work the following way: 1. figure out what files to update 2. apply the update to disk 3. apply the update to in-memory dirstate 4. write dirstate where step3 looks at the filesystem and assumes it sees the result of step2. If a file is changed between step2 and step3, step3 will record incorrect information in the dirstate. I avoid this by passing the size step3 needs directly from step2, for the common path (not implemented for change/delete conflicts for instance). I didn't fix the same race for the exec bit for now, because it's less likely to be problematic and I had trouble due to the fact that the dirstate stores the permissions differently from the manifest (st_mode vs '' 'l' 'x'), in combination with tests that pretend that symlinks are not supported. However, I moved the lstat from step3 to step2, which should tighten the race window markedly, both for the exec bit and for the mtime. Differential Revision: https://phab.mercurial-scm.org/D6475
Wed, 12 Jun 2019 13:10:52 -0400 worker: support parallelization of functions with return values
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 12 Jun 2019 13:10:52 -0400] rev 42455
worker: support parallelization of functions with return values Currently worker supports running functions that return a progress iterator. Generalize it to handle function that return a progress iterator then a return value. It's unused in this commit, but will be used in the next one. Differential Revision: https://phab.mercurial-scm.org/D6515
Sun, 19 May 2019 16:06:06 -0400 tests: show how the dirstate can end up containing wrong information
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 19 May 2019 16:06:06 -0400] rev 42454
tests: show how the dirstate can end up containing wrong information which can result in bad status output. Concretely, this seems to be easily triggered by having a build system watching the filesystem for changes, and rebuilding files that are both tracked and generated while an update is happening. Differential Revision: https://phab.mercurial-scm.org/D6474
Thu, 23 May 2019 02:05:32 +0200 rust: new rust options in setup.py
Georges Racinet <georges.racinet@octobus.net> [Thu, 23 May 2019 02:05:32 +0200] rev 42453
rust: new rust options in setup.py The --rust global option turns on usage (and by default compilation) of the rust-cpython based mercurial.rustext. Similarly to what's previously done for zstd, there is a --no-rust option for the build_ext subcommand in order not to build mercurial.rustext, allowing for an OS distribution to prebuild it. The HGWITHRUSTEXT environment variable is still honored, and has the same effect as before, but now it works mostly by making the --rust global option defaulting to True, with some special cases for the direct-ffi case (see more about that below) Coincidentally, the --rust flag can also be passed from the make commands, like actually all global options, in the PURE variable make local PURE=--rust This feels inappropriate, though, and we should follow up with a proper make variable for that case. Although the direct-ffi bindings aren't directly useful any more, we keep them at this stage because - they provide a short prototyping path for experiments in which a C extension module has to call into a Rust extension. The proper way of doing that would be to use capsules, and it's best to wait for our pull request onto rust-cpython for that: https://github.com/dgrunwald/rust-cpython/pull/169 - Build support for capsules defined in Rust will probably need to reuse some of what's currently in use for direct-ffi.
Thu, 30 May 2019 09:14:41 +0200 rust: using policy.importrust from Python callers
Georges Racinet <georges.racinet@octobus.net> [Thu, 30 May 2019 09:14:41 +0200] rev 42452
rust: using policy.importrust from Python callers This commit converts all current Python callers of mercurial.rustext to the new policy.importrust system. After this point, going through policy.importrust or policy.importmod (in some more distant future) is mandatory for callers of Rust code outside of Python tests. We felt it to be appropriate to keep Rust-specific tests run inconditionally if the Rust extensions are present.
Wed, 29 May 2019 13:27:56 +0200 rust: module policy with importrust
Georges Racinet <georges.racinet@octobus.net> [Wed, 29 May 2019 13:27:56 +0200] rev 42451
rust: module policy with importrust We introduce two rust+c module policies and a new `policy.importrust()` that makes use of them. This simple approach provides runtime switching of implementations, which is crucial for the performance measurements such as those Octobus does with ASV. It can also be useful for bug analysis. It also has the advantage of making conditionals in Rust callers more uniform, in particular abstracting over specifics like `demandimport` At this point, the build stays unchanged, with the rust-cpython based `rustext` module being built if HGWITHRUSTEXT=cpython. More transparency for the callers, i.e., just using `policy.importmod` would be a much longer term and riskier effort for the following reasons: 1. It would require to define common module boundaries for the three or four cases (pure, c, rust+ext, cffi) and that is premature with the Rust extension currently under heavy development in areas that are outside the scope of the C extensions. 2. It would imply internal API changes that are not currently wished, as the case of ancestors demonstrates. 3. The lack of data or property-like attributes (tp_member and tp_getset) in current `rust-cpython` makes it impossible to achieve direct transparent replacement of pure Python classes by Rust extension code, meaning that the caller sometimes has to be able to make adjustments or provide additional wrapping.
Thu, 13 Jun 2019 23:28:31 +0300 help: add help entry for internals.mergestate
Navaneeth Suresh <navaneeths1998@gmail.com> [Thu, 13 Jun 2019 23:28:31 +0300] rev 42450
help: add help entry for internals.mergestate This patch adds an entry for `internals.mergestate` as suggested by @marmoute. Most of the help text is taken from `merge.mergestate`. Differential Revision: https://phab.mercurial-scm.org/D6448 Differential Revision: https://phab.mercurial-scm.org/D6528
Wed, 12 Jun 2019 17:22:37 +0100 phabricator: use parents.set to always set dependencies
Ian Moody <moz-ian@perix.co.uk> [Wed, 12 Jun 2019 17:22:37 +0100] rev 42449
phabricator: use parents.set to always set dependencies Now that Mercurial's Phabricator instance has been updated to a version that supports the parents.set transaction on revision.edit we can use that to set dependency relationships in patch stacks instead of abusing the summary. This has the advantage that we can use it on every `phabsend` so commit reordering is picked up without spamming changes like abusing the summary would, and using parents.set will clear previous parents unlike parents.add. Differential Revision: https://phab.mercurial-scm.org/D6514
Fri, 31 May 2019 10:12:56 -0700 help: remove repeated word in 'hg help rebase'
amalloy [Fri, 31 May 2019 10:12:56 -0700] rev 42448
help: remove repeated word in 'hg help rebase' Specifically, the second 'with' in 'with which to merge with'. Differential Revision: https://phab.mercurial-scm.org/D6483
Mon, 10 Jun 2019 15:35:06 -0700 rebase: tweak description of inmemory working even w/ dirty working dir
Kyle Lippincott <spectral@google.com> [Mon, 10 Jun 2019 15:35:06 -0700] rev 42447
rebase: tweak description of inmemory working even w/ dirty working dir One of our users was confused because they read this, and then attempted to run `hg rebase` with a dirty working directory, and it still complained. The reason was that they were attempting to rebase the commit they currently had checked out, which (at least with evolve workflows enabled) involves updating the working directory to be based on the newly rebased commit. Differential Revision: https://phab.mercurial-scm.org/D6507
Mon, 10 Jun 2019 13:23:14 -0400 revlog: speed up isancestor
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 10 Jun 2019 13:23:14 -0400] rev 42446
revlog: speed up isancestor Currently, it is implemented on top of commonancestorsheads. Implement it on top of reachableroots instead, as reachableroots could stop walking the graph much sooner than commonancestorsheads. Measuring repo.changelog.isancestorrev on two revisions in a private repository: before: ! wall 0.005175 comb 0.010000 user 0.010000 sys 0.000000 (best of 550) after : ! wall 0.000072 comb 0.000000 user 0.000000 sys 0.000000 (best of 36199) When hg does this kind of operations 1500 times in pull -> bookmarks.comparebookmarks -> bookmarks.validdest, that's 11s that drop from the --profile output. Differential Revision: https://phab.mercurial-scm.org/D6506
Mon, 10 Jun 2019 11:40:43 -0400 dagop: fix documentation of reachableroots
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Mon, 10 Jun 2019 11:40:43 -0400] rev 42445
dagop: fix documentation of reachableroots The previous revset couldn't be correct as it is symmetric in <roots> and <heads>, but reachableroots has no such symmetry. It makes a difference with for instance reachableroots(2, 3) where 2 and 3 are both children of 1. Differential Revision: https://phab.mercurial-scm.org/D6505
Tue, 11 Jun 2019 19:52:16 +0100 phabricator: add --blocker argument to phabsend to specify blocking reviewers
Ian Moody <moz-ian@perix.co.uk> [Tue, 11 Jun 2019 19:52:16 +0100] rev 42444
phabricator: add --blocker argument to phabsend to specify blocking reviewers The way to signal to Conduit that a reviewer is considered blocking is just to wrap their PHID in "blocking()" when including it in the list of PHIDs passed to `reviewers.add`. arc doesn't have a --blocker, instead one is supposed to append a '!' to the end of reviewer names (I think reviewers are usually added in an editor rather than the command line, where '!'s can be more hazardous). moz-phab (Mozilla's arcanist wrapper) does have a --blocker argument, and being explicit like this is also more discoverable. Even `arc diff`'s help doesn't seem to mention the reviewer! syntax. Differential Revision: https://phab.mercurial-scm.org/D6512
Tue, 11 Jun 2019 19:37:19 +0100 phabricator: auto-sanitise API tokens and HTTP cookies from VCR recordings
Ian Moody <moz-ian@perix.co.uk> [Tue, 11 Jun 2019 19:37:19 +0100] rev 42443
phabricator: auto-sanitise API tokens and HTTP cookies from VCR recordings Currently when making VCR recordings one needs to manually sanitise sensitive credentials before committing and submitting them as part of tests. It is easy to imagine this being accidentally missed one time by a fallible human and said credentials being leaked. It is also possible that it wouldn't be noticed to alert the user to the leak since the recording files are so large and practically unreviewable. Thus do so automatically, so the only place that needs checking is in the test-phabricator.t file. Differential Revision: https://phab.mercurial-scm.org/D6513
Tue, 11 Jun 2019 15:46:07 +0300 py3: use .startswith() instead of bytes[0]
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 11 Jun 2019 15:46:07 +0300] rev 42442
py3: use .startswith() instead of bytes[0] Doing bytes[0] will return the ascii value of that position which breaks comparison with a bytechar. This makes test-absorb.t work again on py3. Differential Revision: https://phab.mercurial-scm.org/D6508
Sun, 09 Jun 2019 22:23:41 +0900 revset: fix merge() to fall back to changectx API if wdir specified
Yuya Nishihara <yuya@tcha.org> [Sun, 09 Jun 2019 22:23:41 +0900] rev 42441
revset: fix merge() to fall back to changectx API if wdir specified I have a code which basically runs "0:wdir() & <user-revset>", and it crashed if merge() were passed in.
Sun, 09 Jun 2019 22:18:22 +0900 revset: use nullrev constant in merge()
Yuya Nishihara <yuya@tcha.org> [Sun, 09 Jun 2019 22:18:22 +0900] rev 42440
revset: use nullrev constant in merge()
Fri, 31 May 2019 22:38:04 -0700 mixedrepostorecache: fix a silly redundant updating of set
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 May 2019 22:38:04 -0700] rev 42439
mixedrepostorecache: fix a silly redundant updating of set Differential Revision: https://phab.mercurial-scm.org/D6470
Thu, 06 Jun 2019 18:37:21 +0200 rust-regex: fix shortcut for exact matches
Raphaël Gomès <rgomes@octobus.net> [Thu, 06 Jun 2019 18:37:21 +0200] rev 42438
rust-regex: fix shortcut for exact matches The current shortcut for rootglobs that can be simplified to exact matches does not work, it instead treats the pattern as a regex, which is not the same thing. This changes fixes the behavior and introduces a test for this behavior. Differential Revision: https://phab.mercurial-scm.org/D6489
Thu, 06 Jun 2019 15:30:56 +0200 rust-filepatterns: use bytes instead of String
Raphaël Gomès <rgomes@octobus.net> [Thu, 06 Jun 2019 15:30:56 +0200] rev 42437
rust-filepatterns: use bytes instead of String In my initial patch, I introduced an unnecessary hard constraint on UTF-8 filenames and patterns which I forgot to remove. Although the performance penalty for using String might be negligible, we don't want to break compatibility with non-UTF-8 encodings for no reason. Moreover, this change allows for a cleaner Rust core API. This patch introduces a new utils module that is used with this fix. Finally, PatternError was not put inside the Python module generated by Rust, which would have raised a NameError. Differential Revision: https://phab.mercurial-scm.org/D6485
Sat, 01 Jun 2019 01:24:49 +0200 doc: fix description of "predecessors" to match reality
Joerg Sonnenberger <joerg@bec.de> [Sat, 01 Jun 2019 01:24:49 +0200] rev 42436
doc: fix description of "predecessors" to match reality Differential Revision: https://phab.mercurial-scm.org/D6467
Sat, 08 Jun 2019 18:48:06 +0300 phabricator: make `hg debugcallconduit` work outside a hg repo
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 08 Jun 2019 18:48:06 +0300] rev 42435
phabricator: make `hg debugcallconduit` work outside a hg repo I am trying to write some automations around phabricator and having debugcallconduit work outside a hg repo will be nice! Marking command as optionalrepo instead of norepo because we might to load repo/.hg/hgrc. Differential Revision: https://phab.mercurial-scm.org/D6499
Sat, 08 Jun 2019 18:41:15 +0300 phabricator: pass ui instead of repo to callconduit
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 08 Jun 2019 18:41:15 +0300] rev 42434
phabricator: pass ui instead of repo to callconduit This will help us make `hg debugcallconduit` work outside a hg repo as next patch will mark that command as no repo. Differential Revision: https://phab.mercurial-scm.org/D6498
Sat, 08 Jun 2019 18:32:12 +0300 phabricator: pass ui into readurltoken instead of passing repo
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 08 Jun 2019 18:32:12 +0300] rev 42433
phabricator: pass ui into readurltoken instead of passing repo The goal of this series is to make `hg debugcallconduit` work outside of a hg repo. This patch, removes requirement of repo object from readurltoken as we only need ui there. It also updates the callers to pass in ui instead of repo. Differential Revision: https://phab.mercurial-scm.org/D6497
Sat, 08 Jun 2019 19:20:31 +0300 py3: add test-contrib-emacs.t to passing tests list
Pulkit Goyal <pulkit@yandex-team.ru> [Sat, 08 Jun 2019 19:20:31 +0300] rev 42432
py3: add test-contrib-emacs.t to passing tests list I installed emacs on the server running buildbot and the test started passing on Python 3. Lets add it to the list of passing test. Differential Revision: https://phab.mercurial-scm.org/D6500
Fri, 07 Jun 2019 20:19:55 +0100 phabricator: add commenting to phabsend for new/updated Diffs
Ian Moody <moz-ian@perix.co.uk> [Fri, 07 Jun 2019 20:19:55 +0100] rev 42431
phabricator: add commenting to phabsend for new/updated Diffs Especially useful when sending updates to existing Revisions so one can specify the sort of changes e.g. "Address review comments" or "Rebase to tip" If the diff content hasn't changed then it only needs a metadata update which doesn't show in the Phabricator updates UI, so don't add a comment that will. Differential Revision: https://phab.mercurial-scm.org/D6496
Wed, 05 Jun 2019 22:09:26 +0300 py3: fix test-bookmarks-corner-case.t
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 05 Jun 2019 22:09:26 +0300] rev 42430
py3: fix test-bookmarks-corner-case.t For some reasons, the output of print was not going through. Replaced that ui.status(). Differential Revision: https://phab.mercurial-scm.org/D6481
Wed, 05 Jun 2019 22:02:57 +0300 py3: fix test-fix-metadata.t
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 05 Jun 2019 22:02:57 +0300] rev 42429
py3: fix test-fix-metadata.t # skip-blame as just b'' prefixes Differential Revision: https://phab.mercurial-scm.org/D6480
Wed, 05 Jun 2019 22:44:38 +0300 py3: add b'' prefix at one place in run-tests.py
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 05 Jun 2019 22:44:38 +0300] rev 42428
py3: add b'' prefix at one place in run-tests.py #skip-blame because just b'' prefix Differential Revision: https://phab.mercurial-scm.org/D6482
Thu, 06 Jun 2019 10:07:14 -0700 copies: separate added/removed files by newline instead of null
Martin von Zweigbergk <martinvonz@google.com> [Thu, 06 Jun 2019 10:07:14 -0700] rev 42427
copies: separate added/removed files by newline instead of null This makes it more consistent with how we encode copies (newline-separated lists of null-separated pairs). This perhaps makes {extras} a little less readable (?) despite avoiding the escaping. I don't know how I feel about this patch. I'm okay with it being queued or dropped. Differential Revision: https://phab.mercurial-scm.org/D6486
Wed, 22 May 2019 09:54:00 -0700 copies: also encode p[12]copies destination as index into "files" list
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 May 2019 09:54:00 -0700] rev 42426
copies: also encode p[12]copies destination as index into "files" list This is mostly for consistency with the filesaddes/filesremoved fields, but it should also save a bit of space. Differential Revision: https://phab.mercurial-scm.org/D6431
Wed, 05 Jun 2019 11:23:25 +0200 discovery: be more conservative when adjusting the sample size
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 05 Jun 2019 11:23:25 +0200] rev 42425
discovery: be more conservative when adjusting the sample size Since 5b34972a0094, the discovery will increase the sample size when it detect a "complex" undecided set. However this detection focussed on the number of roots only, this could regress discovery performance when the undecided set has many roots that eventually get merged into a few heads. To prevent such misbehavior, we adjust the logic to take in account both heads and roots. The sample size will be increased only if both are especially large. Performance testing on the same case as 5b34972a0094, does not show a significant difference.
Thu, 16 May 2019 16:22:20 +0200 rust-dirstate: create dirstate submodule
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 May 2019 16:22:20 +0200] rev 42424
rust-dirstate: create dirstate submodule This change is here to facilitate a future patch that is written in a different file. I expect this module to grow a few different files. Differential Revision: https://phab.mercurial-scm.org/D6389
Wed, 05 Jun 2019 12:51:21 -0400 profiling: show actual time spent in hotpath display
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 05 Jun 2019 12:51:21 -0400] rev 42423
profiling: show actual time spent in hotpath display To get, for instance: ... \ 6.6% 4.08s lock.py: __exit__ line 1566: ... | 6.5% 4.01s exchange.py: close line 1191: ... | 6.5% 4.01s transaction.py: _active line 1443: ... | 6.5% 4.01s transaction.py: close line 47: ... | 6.2% 3.84s scmutil.py: wrapped line 529: ... | 6.2% 3.81s localrepo.py: wrapper line 2114: ... | 6.2% 3.81s localrepo.py: updatecaches line 177: ... ... instead of: ... \ 6.6% lock.py: __exit__ line 1566: ... | 6.5% exchange.py: close line 1191: ... | 6.5% transaction.py: _active line 1443: ... | 6.5% transaction.py: close line 47: ... | 6.2% scmutil.py: wrapped line 529: ... | 6.2% localrepo.py: wrapper line 2114: ... | 6.2% localrepo.py: updatecaches line 177: ... ... I find that if it's not displayed, I frequently end up estimating the numbers by hand. Differential Revision: https://phab.mercurial-scm.org/D6477
Wed, 05 Jun 2019 14:29:44 -0700 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 05 Jun 2019 14:29:44 -0700] rev 42422
merge with stable
Fri, 31 May 2019 22:37:14 -0700 bookmarks: use correct store for "ambiguity check" stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 May 2019 22:37:14 -0700] rev 42421
bookmarks: use correct store for "ambiguity check" I still don't quite know what the check does, but I clearly got it wrong in 526750cdd02d (bookmarks: keep bookmarks in .hg/store if new config set, 2019-05-15). Just compare with the strings we use in @repofilecache and @storecache. These bugs were then copied to the stable branch in c2b83c957621 (localrepo: grab mixedrepostorecache class from 526750cdd02d, 2019-05-20) and 2338bdea4474 (bookmark: also make bookmark cache depends of the changelog, 2019-05-20). As a result, test-wireproto-exchangev2.t is flaky on both branches. This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D6469
Wed, 05 Jun 2019 10:18:00 -0400 merge with stable
Augie Fackler <augie@google.com> [Wed, 05 Jun 2019 10:18:00 -0400] rev 42420
merge with stable
Tue, 04 Jun 2019 21:13:35 +0900 root: add template variables pointing to repository directories
Yuya Nishihara <yuya@tcha.org> [Tue, 04 Jun 2019 21:13:35 +0900] rev 42419
root: add template variables pointing to repository directories These paths are useful for GUI applications to detect changes. A GUI process typically monitors .hg and .hg/store directories so that it will be notified on lock/wlock deletion. Alternatively, maybe we can add debugpaths command if we don't want to extend the root command. I'm not sure which will be nicer.
Tue, 04 Jun 2019 20:58:39 +0900 root: add support for -Tformatter option
Yuya Nishihara <yuya@tcha.org> [Tue, 04 Jun 2019 20:58:39 +0900] rev 42418
root: add support for -Tformatter option It's useless right now, but it should just work and I want to add a few more fields.
Thu, 23 May 2019 03:03:36 +0530 narrow: pass the bundle to bundle2.widen_bundle() instead of generating there
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 23 May 2019 03:03:36 +0530] rev 42417
narrow: pass the bundle to bundle2.widen_bundle() instead of generating there This will make the code in narrowwirepeer.py more better for further refactoring. Differential Revision: https://phab.mercurial-scm.org/D6438
Thu, 23 May 2019 02:48:25 +0530 narrow: refactor code around widening complicated by previous patch
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 23 May 2019 02:48:25 +0530] rev 42416
narrow: refactor code around widening complicated by previous patch Previous patch while adding support for using narrow_widen wireproto command, complicated the code a bit. This patch refactors that. Differential Revision: https://phab.mercurial-scm.org/D6437
Wed, 22 May 2019 02:59:48 +0530 narrow: use narrow_widen wireproto command to widen in case of ellipses
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 22 May 2019 02:59:48 +0530] rev 42415
narrow: use narrow_widen wireproto command to widen in case of ellipses Few releases ago, we introduce narrow_widen wireproto command to be used to widen narrow repositories. Before this patch, that was used in non-ellipses cases only. In ellipses cases, we still do exchange.pull() which can pull more data than required. After this patch, the client will first check whether server supports doing ellipses widening using wireproto command or not by checking server's wireproto capability. If the server is upto date and support latest ellipses capability, we call the wireproto command. Otherwise we fallback to exchange.pull() like before. The compat code make sure that things works even if one of the client or server is old. The initial version of this patch does not had this compat code. It's added to help Google release things smoothly internally. I plan to drop the compat code before the upcoming major release. Due to change to wireproto command, the code looks a bit dirty, next patches will clean that up. Differential Revision: https://phab.mercurial-scm.org/D6436
Wed, 05 Jun 2019 10:14:19 -0400 Added signature for changeset c3484ddbdb96 stable
Augie Fackler <raf@durin42.com> [Wed, 05 Jun 2019 10:14:19 -0400] rev 42414
Added signature for changeset c3484ddbdb96
Wed, 05 Jun 2019 10:14:18 -0400 Added tag 5.0.1 for changeset c3484ddbdb96 stable
Augie Fackler <raf@durin42.com> [Wed, 05 Jun 2019 10:14:18 -0400] rev 42413
Added tag 5.0.1 for changeset c3484ddbdb96
Tue, 04 Jun 2019 17:24:35 +0800 merge: correct argument name in docstring
Anton Shestakov <av6@dwimlabs.net> [Tue, 04 Jun 2019 17:24:35 +0800] rev 42412
merge: correct argument name in docstring Differential Revision: https://phab.mercurial-scm.org/D6476
Fri, 31 May 2019 15:28:31 -0700 narrowspec: replace one recursion-avoidance hack with another
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 May 2019 15:28:31 -0700] rev 42411
narrowspec: replace one recursion-avoidance hack with another When updating the working copy narrowspec, we call context.walk() in order to find which files to update the working copy with. context.walk() calls repo.narrowmatch(). In order to avoid infinite recursion in this case, we have a hack that assigns the new values for repo.narrowpats and repo._narrowmatch. However, doing that of course breaks future invalidation of those properties (they're @storecache'd). Let's instead avoid the infinite recursion by setting a flag on the repo instance when we're updating the working copy. Differential Revision: https://phab.mercurial-scm.org/D6468
Sat, 09 Mar 2019 22:13:06 -0800 merge: simplify initialization of "pas"
Martin von Zweigbergk <martinvonz@google.com> [Sat, 09 Mar 2019 22:13:06 -0800] rev 42410
merge: simplify initialization of "pas" Differential Revision: https://phab.mercurial-scm.org/D6472
Sat, 09 Mar 2019 22:11:27 -0800 merge: reorder some initialization to make more sense
Martin von Zweigbergk <martinvonz@google.com> [Sat, 09 Mar 2019 22:11:27 -0800] rev 42409
merge: reorder some initialization to make more sense This puts the closely related definitions of "pl", "p1", "p2", "pas" close together, and moves the definition of "overwrite" away and closer to where it's first used. Differential Revision: https://phab.mercurial-scm.org/D6471
Wed, 22 May 2019 08:27:02 +0000 rust-dirstate: architecture independence fix
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 May 2019 08:27:02 +0000] rev 42408
rust-dirstate: architecture independence fix Apparently, c_char is u8 on ppc64le and i8 on amd64 Differential Revision: https://phab.mercurial-scm.org/D6473
Tue, 14 May 2019 22:20:10 -0700 context: get filesadded() and filesremoved() from changeset if configured
Martin von Zweigbergk <martinvonz@google.com> [Tue, 14 May 2019 22:20:10 -0700] rev 42407
context: get filesadded() and filesremoved() from changeset if configured This adds the read side for getting the sets of added and removed files from the changeset extras. I timed this command on the hg repo: hg log -T '{rev}\n {files}\n %:{file_mods}\n +{file_adds}\n -{file_dels}\n' It took 1m21s before and 6.4s after. I also used that command to check that the result didn't change compared to calculating the values from the manifests on the fly (it didn't change). In the mozilla-unified repo, the same command run on FIREFOX_BETA_58_END::FIREFOX_BETA_59_END went from 29s to 0.67s. Differential Revision: https://phab.mercurial-scm.org/D6417
Tue, 14 May 2019 22:19:51 -0700 changelog: optionally store added and removed files in changeset extras
Martin von Zweigbergk <martinvonz@google.com> [Tue, 14 May 2019 22:19:51 -0700] rev 42406
changelog: optionally store added and removed files in changeset extras As mentioned in an earlier patch, copies._chain() is used a lot in the changeset-centric version of pathcopies(). It is expensive because it needs to look at the manifest in order to filter out copies whose target file has since been removed. I want to store the sets of added and removed files in the changeset in order to speed that up. This patch does the writing part of that. It could easily be a separate config, but it's currently tied to experimental.copies.write-to since that's the only real use case (it will also make the {file_*} template keywords faster, but I doubt that anyone cares enough about those to write extra metadata for them). The new information is stored in the changeset extras. Since they're always subsets of the changeset's "files" list, they're stored as indexes into that list. I've stored the indexes as stringified ints separated by NUL bytes. The size of 00changelog.d for the hg repo increased in size by 0.28% percent (compared to the size with only copy information in the changesets, which in turn is 0.17% larger than without copy information). We could store only the delta between the indexes and we could store them in binary, but the chosen format is more readable. We could also have implemented this as a cache outside the changelog. One advantage of doing it that way is that we would get the speedups from the {file_*} template keywords also on old repos. Another advantage is that it we can rewrite the cache if we find a bug in how we calculate the set of files. A disadvantage is that it would be more complex. Another is that it would surely use more space. We already write the copy information to the changeset extras, so it seems like a small step to also write these file sets. Differential Revision: https://phab.mercurial-scm.org/D6416
Thu, 18 Apr 2019 13:35:02 -0700 templatekw: make {file_*} compare to both merge parents (issue4292)
Martin von Zweigbergk <martinvonz@google.com> [Thu, 18 Apr 2019 13:35:02 -0700] rev 42405
templatekw: make {file_*} compare to both merge parents (issue4292) This redefines the {file_adds}, {file_dels}, {file_mods} template keywords by getting the lists from the recently introduced context methods instead of getting them from status compared to p1. As mentioned before, these are better defined on merge commits. The total number of files from the three lists now always add up to the number of files in {files}. I timed this command: hg log -r 4.0::5.0 -T '{rev}\n {file_mods}\n {file_adds}\n {file_dels}\n' It went from 7.6s to 5.6s with this patch. So it's actually faster than before. Note that the "files:" field in the bazaar test log output was using "{file_mods}" (not "{files}" as one might think based on the label). Differential Revision: https://phab.mercurial-scm.org/D6369
Fri, 31 May 2019 09:25:51 -0700 narrowspec: use vfs.tryread() instead of reimplementing
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 May 2019 09:25:51 -0700] rev 42404
narrowspec: use vfs.tryread() instead of reimplementing Note that parseconfig() works well with empty strings. Differential Revision: https://phab.mercurial-scm.org/D6465
Fri, 31 May 2019 13:25:28 -0700 help: remove a superfluous "the" in revlogs text
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 May 2019 13:25:28 -0700] rev 42403
help: remove a superfluous "the" in revlogs text Differential Revision: https://phab.mercurial-scm.org/D6466
Thu, 08 Mar 2018 11:08:24 -0800 setdiscovery: make progress on most connected groups each roundtrip
Martin von Zweigbergk <martinvonz@google.com> [Thu, 08 Mar 2018 11:08:24 -0800] rev 42402
setdiscovery: make progress on most connected groups each roundtrip Consider history like this: o | o | | | o | | | o |/ o | o | | | o | | | o |/ o | o | | | o | | | o |/ o ~ Assume the left mainline is available in the remote repo and the other commits are only in the local repo. Also imagine that instead of 3 local branches with 3 commits on each, there are 1000 branches (the number of commits on each doesn't matter much here). In such a scenario, the current setdiscovery code will pick a sample size of 200 among these branches and ask the remote which of them it has. However, the discovery for each such branch is completely independent of the discovery for the others -- knowing whether the remote has a commit in one branch doesn't give us any information about the other branches. The discovery will therefore take at least 5 roundtrips (maybe more depending on which commit in each linear chain was sampled). Since the discovery for each branch is independent, there is no reason to let one branch wait for another, so this patch makes it so we sample at least as many commits as there are branches. It may still happen (it's very likely, even) that we get multiple samples from one branch and none from another, but that will even out over a few rounds and I think this is still a big improvement. Because of http header size limits, we still use the old behavior unless experimental.httppostargs=true. I've timed this by running `hg debugdiscovery mozilla-unified --debug` in the mozilla-try repo. Both repos were local. Before this patch, last part of the output was: 2249 total queries in 5276.4859s elapsed time: 5276.652634 seconds heads summary: total common heads: 13 also local heads: 4 also remote heads: 8 both: 4 local heads: 28317 common: 4 missing: 28313 remote heads: 12 common: 8 unknown: 4 local changesets: 2014901 common: 530373 missing: 1484528 common heads: 1dad417c28ad 4a108e94d3e2 4d7ef530fffb 5350524bb654 777e60ca8853 7d97fafba271 9cd2ab4d0029 a55ce37217da d38398e5144e dcc6d7a0dc00 e09297892ada e24ec6070d7b fd559328eaf3 After this patch, the output was (including all the samples, since there were so few now): taking initial sample query 2; still undecided: 1599476, sample size is: 108195 sampling from both directions query 3; still undecided: 810922, sample size is: 194158 sampling from both directions query 4; still undecided: 325882, sample size is: 137302 sampling from both directions query 5; still undecided: 111459, sample size is: 74586 sampling from both directions query 6; still undecided: 26805, sample size is: 23960 sampling from both directions query 7; still undecided: 2549, sample size is: 2528 sampling from both directions query 8; still undecided: 21, sample size is: 21 8 total queries in 24.5064s elapsed time: 24.670051 seconds heads summary: total common heads: 13 also local heads: 4 also remote heads: 8 both: 4 local heads: 28317 common: 4 missing: 28313 remote heads: 12 common: 8 unknown: 4 local changesets: 2014901 common: 530373 missing: 1484528 common heads: 1dad417c28ad 4a108e94d3e2 4d7ef530fffb 5350524bb654 777e60ca8853 7d97fafba271 9cd2ab4d0029 a55ce37217da d38398e5144e dcc6d7a0dc00 e09297892ada e24ec6070d7b fd559328eaf3 Differential Revision: https://phab.mercurial-scm.org/D2647
Tue, 28 May 2019 14:39:26 -0400 help: clarify overlap of revlog header and first revlog entry
Nathan Goldbaum <nathan12343@gmail.com> [Tue, 28 May 2019 14:39:26 -0400] rev 42401
help: clarify overlap of revlog header and first revlog entry Differential Revision: https://phab.mercurial-scm.org/D6449
Wed, 29 May 2019 21:40:41 +0300 py3: fix test-convert-svn-sink.t
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 29 May 2019 21:40:41 +0300] rev 42400
py3: fix test-convert-svn-sink.t In cases where the root commit is empty commit, None will be returned as parents. This was implemented by 2c13e91ede6e. This breaks test on py3 because `b'%s' % None` does not work. It does not matter whether we return `None` or `'None'` as we skipped converting to svn step by doing an early return. So let's return `'None'`. I tried to patch all the users to convert `None` to `'None'`, but there were more users than I expected. I hit 3 of them and decided to fix it this way around. Differential Revision: https://phab.mercurial-scm.org/D6458
Thu, 30 May 2019 13:57:34 -0700 commit: respect --no-edit in combination with --amend
Kyle Lippincott <spectral@google.com> [Thu, 30 May 2019 13:57:34 -0700] rev 42399
commit: respect --no-edit in combination with --amend Differential Revision: https://phab.mercurial-scm.org/D6464
Thu, 30 May 2019 14:14:52 -0700 commit: add test showing that commit --amend --no-edit still shows editor
Kyle Lippincott <spectral@google.com> [Thu, 30 May 2019 14:14:52 -0700] rev 42398
commit: add test showing that commit --amend --no-edit still shows editor Differential Revision: https://phab.mercurial-scm.org/D6463
Thu, 30 May 2019 16:42:38 +0800 githelp: translate git stash show and clear actions and --patch flag
Anton Shestakov <av6@dwimlabs.net> [Thu, 30 May 2019 16:42:38 +0800] rev 42397
githelp: translate git stash show and clear actions and --patch flag Differential Revision: https://phab.mercurial-scm.org/D6461
Thu, 30 May 2019 16:40:34 +0800 githelp: add --dry-run for mv
Anton Shestakov <av6@dwimlabs.net> [Thu, 30 May 2019 16:40:34 +0800] rev 42396
githelp: add --dry-run for mv Differential Revision: https://phab.mercurial-scm.org/D6460
Thu, 30 May 2019 16:38:42 +0800 githelp: translate --directory of git apply to --prefix
Anton Shestakov <av6@dwimlabs.net> [Thu, 30 May 2019 16:38:42 +0800] rev 42395
githelp: translate --directory of git apply to --prefix According to the help pages, these flags do the same. Differential Revision: https://phab.mercurial-scm.org/D6459
Thu, 23 May 2019 11:14:32 -0400 help: include subtopic in error message if passed
Nathan Goldbaum <nathan12343@gmail.com> [Thu, 23 May 2019 11:14:32 -0400] rev 42394
help: include subtopic in error message if passed Differential Revision: https://phab.mercurial-scm.org/D6442
Thu, 23 May 2019 10:47:10 -0400 help: check if a subtopic exists and raise an error if it doesn't (issue6145)
Nathan Goldbaum <nathan12343@gmail.com> [Thu, 23 May 2019 10:47:10 -0400] rev 42393
help: check if a subtopic exists and raise an error if it doesn't (issue6145) Differential Revision: https://phab.mercurial-scm.org/D6441
Wed, 29 May 2019 10:00:54 -0400 perf: fix some missing b prefixes
Augie Fackler <augie@google.com> [Wed, 29 May 2019 10:00:54 -0400] rev 42392
perf: fix some missing b prefixes # skip-blame just b prefixes Differential Revision: https://phab.mercurial-scm.org/D6457
Wed, 29 May 2019 10:00:30 -0400 testparseutil: fix doctest to use str instead of bytes
Augie Fackler <augie@google.com> [Wed, 29 May 2019 10:00:30 -0400] rev 42391
testparseutil: fix doctest to use str instead of bytes Differential Revision: https://phab.mercurial-scm.org/D6456
Wed, 29 May 2019 09:59:35 -0400 testparseutil: stop extracting using std* streams as bytes on py3
Augie Fackler <augie@google.com> [Wed, 29 May 2019 09:59:35 -0400] rev 42390
testparseutil: stop extracting using std* streams as bytes on py3 This is no longer required due to other cleanups in our linting tools. Differential Revision: https://phab.mercurial-scm.org/D6455
Wed, 29 May 2019 09:56:27 -0400 tests: sort some imports that were previously missed
Augie Fackler <augie@google.com> [Wed, 29 May 2019 09:56:27 -0400] rev 42389
tests: sort some imports that were previously missed I'm a little unclear why the import checker didn't catch this before, but when I fixed it to work in Python 3 this failure started showing up. Sigh. Differential Revision: https://phab.mercurial-scm.org/D6454
Wed, 29 May 2019 09:55:35 -0400 contrib: fix import-checker to operate on str instead of bytes
Augie Fackler <augie@google.com> [Wed, 29 May 2019 09:55:35 -0400] rev 42388
contrib: fix import-checker to operate on str instead of bytes I believe this is fallout from other Python 3 cleanups, and our code linting tools are now leaning towards operating on str and not bytes. I don't feel strongly, so I've just restored this tool to working on Python 3. Differential Revision: https://phab.mercurial-scm.org/D6453
Tue, 28 May 2019 16:12:11 -0700 verify: use self._err not self.err, it changed in 7eaf4b1ac2a3
Kyle Lippincott <spectral@google.com> [Tue, 28 May 2019 16:12:11 -0700] rev 42387
verify: use self._err not self.err, it changed in 7eaf4b1ac2a3 Differential Revision: https://phab.mercurial-scm.org/D6451
Tue, 28 May 2019 23:22:46 -0700 tests: make run-tests exit non-zero if there are "errors"
Kyle Lippincott <spectral@google.com> [Tue, 28 May 2019 23:22:46 -0700] rev 42386
tests: make run-tests exit non-zero if there are "errors" Previously, if there was an error such as a broken .t file that caused run-tests.py to encounter an exception during parsing, the test would be considered in an "errored" state, which is separate from "failed". The check for whether to exit non-zero or not was based entirely on whether there were any tests in a "failed" state, so if there was only an error, run-tests would exit with 0. Our test infrastructure would then consider the test as passing, causing us to have some tests with false negatives that have gone undetected for a few weeks now. Differential Revision: https://phab.mercurial-scm.org/D6452
(0) -30000 -10000 -3000 -1000 -120 +120 +1000 +3000 tip