Wed, 16 Jan 2019 10:57:38 -0500 remotefilelog: fix logging in retry decorator
Augie Fackler <augie@google.com> [Wed, 16 Jan 2019 10:57:38 -0500] rev 41250
remotefilelog: fix logging in retry decorator This still fails with an error about no exception being available to re-raise, but so it goes. Differential Revision: https://phab.mercurial-scm.org/D5600
Wed, 16 Jan 2019 10:56:15 -0500 basepack: avoid 'rbe' mode in Python 3
Augie Fackler <augie@google.com> [Wed, 16 Jan 2019 10:56:15 -0500] rev 41249
basepack: avoid 'rbe' mode in Python 3 Differential Revision: https://phab.mercurial-scm.org/D5598
Wed, 16 Jan 2019 10:55:42 -0500 remotefilelog: do file IO in terms of bytes
Augie Fackler <augie@google.com> [Wed, 16 Jan 2019 10:55:42 -0500] rev 41248
remotefilelog: do file IO in terms of bytes Differential Revision: https://phab.mercurial-scm.org/D5597
Fri, 30 Nov 2018 14:35:57 +0100 rust-cpython: using MissingAncestors from Python code
Georges Racinet <georges.racinet@octobus.net> [Fri, 30 Nov 2018 14:35:57 +0100] rev 41247
rust-cpython: using MissingAncestors from Python code As precedently done with LazyAncestors on cpython.rs, we test for the presence of the 'rustext' module. incrementalmissingrevs() has two callers within the Mercurial core: `setdiscovery.partialdiscovery` and the `only()` revset. This move shows a significant discovery performance improvement in cases where the baseline is slow: using perfdiscovery on the PyPy repos, prepared with `contrib/discovery-helper <repo> 50 100`, we get averaged medians of 403ms with the Rust version vs 742ms without (about 45% better). But there are still indications that performance can be worse in cases the baseline is fast, possibly due to the conversion from Python to Rust and back becoming the bottleneck. We could measure this on mozilla-central in cases were the delta is just a few changesets. This requires confirmation, but if that's the reason, then an upcoming `partialdiscovery` fully in Rust should solve the problem. Differential Revision: https://phab.mercurial-scm.org/D5551
Mon, 14 Jan 2019 17:07:39 +0100 rust: MissingAncestors.basesheads()
Georges Racinet <georges.racinet@octobus.net> [Mon, 14 Jan 2019 17:07:39 +0100] rev 41246
rust: MissingAncestors.basesheads() This new API method on `MissingAncestors` leverages directly the Rust implementation for relative heads of a set, and also lowers the cost of returning the results to Python in the context of discovery. These interchange costs can probably be further reduced by implementing the `partialdiscovery` class in Rust, but that will be investigated in the 5.0 development cycle. Differential Revision: https://phab.mercurial-scm.org/D5584
Mon, 14 Jan 2019 18:52:01 +0100 discovery: using the new basesheads()
Georges Racinet <georges.racinet@octobus.net> [Mon, 14 Jan 2019 18:52:01 +0100] rev 41245
discovery: using the new basesheads() Our ultimate goal is to switch eventually to a Rust implementation, but this move actually seems to increase the performance in a pure Python build. What follows is a quick measurement done on PyPy on repos prepared with `contrib/discovery-helper.sh 50 100`. Before: ! wall 0.894384 comb 0.890000 user 0.890000 sys 0.000000 (best of 11) ! wall 0.971199 comb 0.970000 user 0.950000 sys 0.020000 (max of 11) ! wall 0.927993 comb 0.925455 user 0.919091 sys 0.006364 (avg of 11) ! wall 0.921619 comb 0.920000 user 0.910000 sys 0.010000 (median of 11) After: ! wall 0.614278 comb 0.610000 user 0.610000 sys 0.000000 (best of 14) ! wall 0.789459 comb 0.790000 user 0.770000 sys 0.020000 (max of 14) ! wall 0.722765 comb 0.720000 user 0.715714 sys 0.004286 (avg of 14) ! wall 0.734448 comb 0.720000 user 0.720000 sys 0.000000 (median of 14) Differential Revision: https://phab.mercurial-scm.org/D5583
Mon, 14 Jan 2019 18:36:09 +0100 ancestor: incrementalmissingancestors.basesheads()
Georges Racinet <georges.racinet@octobus.net> [Mon, 14 Jan 2019 18:36:09 +0100] rev 41244
ancestor: incrementalmissingancestors.basesheads() This new method will avoid the need to access the `bases` attribute directly in `setdiscovery`, and to prefilter `nullrev` before passing it to the `heads()` revset. Being a method, it can transparently be reimplemented in a Rust (or any native) version. Differential Revision: https://phab.mercurial-scm.org/D5582
Mon, 14 Jan 2019 17:46:14 +0100 rust-cpython: set conversion for MissingAncestors.bases()
Georges Racinet <georges.racinet@octobus.net> [Mon, 14 Jan 2019 17:46:14 +0100] rev 41243
rust-cpython: set conversion for MissingAncestors.bases() Also I hope that the separate `py_set()` helper will help transition to proper `PySet` support in `rust-cpython` Took the opportunity to replace explict for loop with iteration and collect(). Differential Revision: https://phab.mercurial-scm.org/D5581
Mon, 14 Jan 2019 10:07:48 +0100 rust: dagop.headrevs() Rust counterparts
Georges Racinet on ishtar.racinet.fr <georges@racinet.fr> [Mon, 14 Jan 2019 10:07:48 +0100] rev 41242
rust: dagop.headrevs() Rust counterparts This introduces two Rust implementations for `mercurial.dagop.headrevs`. The algorithm is identical to the Python version. Depending on the caller, one or the other could be the most practical, or the most performant, by minimizing the amount of memory copy and allocations. Differential Revision: https://phab.mercurial-scm.org/D5580
Mon, 14 Jan 2019 20:42:25 +0100 rust: factorized testing Graphs
Georges Racinet <georges.racinet@octobus.net> [Mon, 14 Jan 2019 20:42:25 +0100] rev 41241
rust: factorized testing Graphs it will useful to use these outside of `ancestors`, too. Differential Revision: https://phab.mercurial-scm.org/D5579
Sat, 12 Jan 2019 16:57:04 +0100 rust-cpython: moved generic conversion fn out of ancestors module
Georges Racinet <georges.racinet@octobus.net> [Sat, 12 Jan 2019 16:57:04 +0100] rev 41240
rust-cpython: moved generic conversion fn out of ancestors module This will allow to use it easily from other submodules Differential Revision: https://phab.mercurial-scm.org/D5578
Tue, 15 Jan 2019 20:24:17 +0100 revset: transparently forward _intlist argument in all case
Boris Feld <boris.feld@octobus.net> [Tue, 15 Jan 2019 20:24:17 +0100] rev 41239
revset: transparently forward _intlist argument in all case We took a safe approach for the first take, we can get bolder now.
Sun, 30 Dec 2018 00:15:38 -0800 narrow: reuse narrowspec.updateworkingcopy() when narrowing
Martin von Zweigbergk <martinvonz@google.com> [Sun, 30 Dec 2018 00:15:38 -0800] rev 41238
narrow: reuse narrowspec.updateworkingcopy() when narrowing Similar to the previous patch for widening, but here we also need to teach updateworkingcopy() to forcefully delete files that are not recorded in the dirstate as clean. That should be safe because the narrowing command (e.g. `hg tracked --removeinclude`) has already checked that the working copy is clean. Differential Revision: https://phab.mercurial-scm.org/D5511
Fri, 21 Dec 2018 10:05:37 -0800 narrow: reuse narrowspec.updateworkingcopy() when widening
Martin von Zweigbergk <martinvonz@google.com> [Fri, 21 Dec 2018 10:05:37 -0800] rev 41237
narrow: reuse narrowspec.updateworkingcopy() when widening The widening of the working copy we do after widening a repo is practically the same as we do in a repo share after the store narrowspec has been changed in a different share. Let's reuse the code for that that we now have in the narrowspec module. Differential Revision: https://phab.mercurial-scm.org/D5510
Sat, 29 Dec 2018 23:40:18 -0800 narrow: move copytonarrowspec() out of setnarrowpats()
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 23:40:18 -0800] rev 41236
narrow: move copytonarrowspec() out of setnarrowpats() I think it was a mistake to write the working copy's narrowspec every time the store narrowspec is written. This starts separating those actions. Differential Revision: https://phab.mercurial-scm.org/D5509
Sat, 29 Dec 2018 23:09:07 -0800 narrow: drop now-unnecessary reassignment of repo attributes
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 23:09:07 -0800] rev 41235
narrow: drop now-unnecessary reassignment of repo attributes Differential Revision: https://phab.mercurial-scm.org/D5507
Fri, 11 Jan 2019 14:55:31 +0100 packaging: allow running packaging with custom uid+gid for CentOS
Mathias De Mare <mathias.de_mare@nokia.com> [Fri, 11 Jan 2019 14:55:31 +0100] rev 41234
packaging: allow running packaging with custom uid+gid for CentOS rpmbuild in CentOS 7 has a bug causing rpmbuild to fail with "Bad owner/group" if spec or source files are owned by a different user: https://github.com/rpm-software-management/rpm/issues/2 This makes it very annoying to try and build the CentOS RPMs on CentOS with Docker. As an alternative, this change makes it possible to do so, using an environment variable. Differential Revision: https://phab.mercurial-scm.org/D5571
Fri, 11 Jan 2019 13:14:25 +0100 hg-docker: fix Python 3.4 compatibility (for CentOS 7)
Mathias De Mare <mathias.de_mare@nokia.com> [Fri, 11 Jan 2019 13:14:25 +0100] rev 41233
hg-docker: fix Python 3.4 compatibility (for CentOS 7) I realize Mercurial is not targetting Python 3.4 compatibility, but without this change, it's not even possible to build it on CentOS 7 (and I assume the same is true for RHEL 7). Differential Revision: https://phab.mercurial-scm.org/D5570
Tue, 15 Jan 2019 11:07:34 -0800 copies: use node.nullrev instead of literal -1
Martin von Zweigbergk <martinvonz@google.com> [Tue, 15 Jan 2019 11:07:34 -0800] rev 41232
copies: use node.nullrev instead of literal -1 Differential Revision: https://phab.mercurial-scm.org/D5593
Tue, 15 Jan 2019 09:20:47 -0800 copies: use node.wdirrev instead of inventing another constant for it
Martin von Zweigbergk <martinvonz@google.com> [Tue, 15 Jan 2019 09:20:47 -0800] rev 41231
copies: use node.wdirrev instead of inventing another constant for it Differential Revision: https://phab.mercurial-scm.org/D5592
Sat, 29 Dec 2018 23:35:05 -0800 narrow: extract repo property for store narrowmatcher
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 23:35:05 -0800] rev 41230
narrow: extract repo property for store narrowmatcher When a repo lock is released, we try to persist the manifest cache. That involves getting the narrowmatcher for the manifestlog. That should not fail if the store and working copy narrowspecs are out of sync. Without this patch, the later patches in this series will fail because of that. Differential Revision: https://phab.mercurial-scm.org/D5508
Sat, 29 Dec 2018 23:01:12 -0800 narrow: copy store narrowspec to working copy immediately
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 23:01:12 -0800] rev 41229
narrow: copy store narrowspec to working copy immediately We no longer need to delay it until the end of the transaction since we now restore a backup if the transaction aborts. Differential Revision: https://phab.mercurial-scm.org/D5506
Sat, 29 Dec 2018 22:34:38 -0800 narrow: include working copy narrowspec in transaction journal
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 22:34:38 -0800] rev 41228
narrow: include working copy narrowspec in transaction journal Now that we have separate narrowspecs for the store and the working copy, we need to include both in the transaction journal. Differential Revision: https://phab.mercurial-scm.org/D5505
Sat, 29 Dec 2018 22:27:39 -0800 narrow: make dirstateguard back up and restore working copy narrowspec instead
Martin von Zweigbergk <martinvonz@google.com> [Sat, 29 Dec 2018 22:27:39 -0800] rev 41227
narrow: make dirstateguard back up and restore working copy narrowspec instead We used to have only one narrowspec for the store and the working copy, but now that we have one narrowspec for each, it seems clear that the dirstateguard was supposed to back up and restore the narrowspec associated with the working copy, not the one associated with the store. clearbackup() (for the store narrowspec) is not needed because the presence of the file in localrepository._journalfiles() takes care of that. Differential Revision: https://phab.mercurial-scm.org/D5504
Thu, 10 Jan 2019 13:36:25 -0800 narrow: include journal.narrowspec in transaction journal
Martin von Zweigbergk <martinvonz@google.com> [Thu, 10 Jan 2019 13:36:25 -0800] rev 41226
narrow: include journal.narrowspec in transaction journal We had missed this file before, which led to it lying around after the transaction completed. Differential Revision: https://phab.mercurial-scm.org/D5556
Tue, 08 Jan 2019 09:50:40 -0800 progress: deprecate ui.progress()
Martin von Zweigbergk <martinvonz@google.com> [Tue, 08 Jan 2019 09:50:40 -0800] rev 41225
progress: deprecate ui.progress() It is now just a weird wrapper for ui.makeprogress(). Differential Revision: https://phab.mercurial-scm.org/D5531
Tue, 15 Jan 2019 15:43:00 -0800 context: use scmutil.matchfiles instead of matchmod.match(exact=True)
Kyle Lippincott <spectral@google.com> [Tue, 15 Jan 2019 15:43:00 -0800] rev 41224
context: use scmutil.matchfiles instead of matchmod.match(exact=True) Differential Revision: https://phab.mercurial-scm.org/D5591
Mon, 14 Jan 2019 22:19:43 -0500 histedit: fix call to _getgoal() by adding a byteskwargs() wrapper
Augie Fackler <augie@google.com> [Mon, 14 Jan 2019 22:19:43 -0500] rev 41223
histedit: fix call to _getgoal() by adding a byteskwargs() wrapper I also added some b-prefixes while I was here because I got confused and it seems silly to not just add them since it clarifies the whole change. Differential Revision: https://phab.mercurial-scm.org/D5585
Fri, 04 Jan 2019 13:41:21 +0100 revset: introduce an API that avoids `formatspec` input serialization
Boris Feld <boris.feld@octobus.net> [Fri, 04 Jan 2019 13:41:21 +0100] rev 41222
revset: introduce an API that avoids `formatspec` input serialization Instead of having the data fully serialized, the input can be directly inserted in the tree at a later stage. Just using it for simple "%ld" case provide a significant boost. For example here are the impact on a sample discovery run between two pypy repositories with arbitrary differences (using hg perfdiscovery). $ hg perfdiscovery before: ! wall 0.700435 comb 0.710000 user 0.700000 sys 0.010000 (median of 15) after: ! wall 0.501305 comb 0.510000 user 0.490000 sys 0.020000 (median of 20)
Fri, 04 Jan 2019 05:26:13 +0100 revset: detect integer list on parsing
Boris Feld <boris.feld@octobus.net> [Fri, 04 Jan 2019 05:26:13 +0100] rev 41221
revset: detect integer list on parsing Right now, using "%ld" with `repo.revs("…%ld…", somerevs)` is very inefficient, all items in `somerevs` will be serialized to ascii and then reparsed as integers. If `somerevs` contains just an handful of entry this is fine, however, when you get to thousands or hundreds of thousands of revisions this becomes very slow. To avoid this serialization we need to first detect this situation. The code involved in the whole process is quite complex so we start simple and focus on some "simple" but widespread cases. So far we only detect the situation and don't do anything special about it. The singled out will be serialized in `formatspec` in the same way as before.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip