Thu, 14 Mar 2019 17:57:31 +0000 rust-discovery: implementing and exposing stats()
Georges Racinet <georges.racinet@octobus.net> [Thu, 14 Mar 2019 17:57:31 +0000] rev 42180
rust-discovery: implementing and exposing stats() This time, it's simple enough that we can do it in all layers in one shot. Differential Revision: https://phab.mercurial-scm.org/D6233
Wed, 20 Feb 2019 09:04:39 +0100 rust-discovery: cpython bindings for the core logic
Georges Racinet <georges.racinet@octobus.net> [Wed, 20 Feb 2019 09:04:39 +0100] rev 42179
rust-discovery: cpython bindings for the core logic As previously done with the ancestors submodule, testing for the bindings is provided from Python on a trivial case. Differential Revision: https://phab.mercurial-scm.org/D6232
Tue, 19 Feb 2019 23:42:31 +0100 rust-discovery: starting core implementation
Georges Racinet <georges.racinet@octobus.net> [Tue, 19 Feb 2019 23:42:31 +0100] rev 42178
rust-discovery: starting core implementation Once exposed to the Python side, this core object will avoid costly roundtrips with potentially big sets of revisions. This changeset implements the core logic of the object only, i.e., manipulation of the missing, common and undefined set-like revision attributes. Differential Revision: https://phab.mercurial-scm.org/D6231
Wed, 20 Feb 2019 18:33:53 +0100 rust-dagops: roots
Georges Racinet <georges.racinet@octobus.net> [Wed, 20 Feb 2019 18:33:53 +0100] rev 42177
rust-dagops: roots Unsuprisingly, the algorithm is much easier than for heads, provided we work on a set in the first place. To improve the signature, a trait for set-likes object would be useful, but that's not an immediate concern. Differential Revision: https://phab.mercurial-scm.org/D6230
Tue, 19 Feb 2019 23:41:57 +0100 rust-dagops: range of revisions
Georges Racinet <georges.racinet@octobus.net> [Tue, 19 Feb 2019 23:41:57 +0100] rev 42176
rust-dagops: range of revisions This is a Rust implementation for what reachableroots2() does if includepath is True. The algorithmic details and performance notes are included in the documentation comment. Our main use case for now is a Rust counterpart of the partialdiscovery object, so we don't really need bindings yet. Differential Revision: https://phab.mercurial-scm.org/D6229
Sun, 21 Apr 2019 08:57:01 -0700 setup: tweak error message for Python 3 stable
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 21 Apr 2019 08:57:01 -0700] rev 42175
setup: tweak error message for Python 3 We now have beta support for Python 3. In my opinion, it isn't yet stable enough to allow `pip install Mercurial` to work with Python 3 out of the box: we don't want people accidentally using Mercurial with Python 3 just yet. But I do think we should be more friendly about informing people of their options. This commit tweaks the error message that users see when running setup.py with Python 3. We instruct them about the current level of Python 3 support, point them at the wiki for more info, and give them instructions on how to bypass the check. As part of this, I also changed which version value is printed, as we were printing a named tuple before.
Sun, 21 Apr 2019 07:21:08 -0700 setup: remove set and dict comprehensions stable
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 21 Apr 2019 07:21:08 -0700] rev 42174
setup: remove set and dict comprehensions Yuya observed in a recent review that it is worthwhile to keep setup.py parseable with Python 2.6 so a useful error message is seen when attempting to run with Python 2.6. This commit removes a set and dict comprehension so setup.py is parseable with Python 2.6.
Fri, 19 Apr 2019 23:13:28 +0300 branchcache: don't verify all nodes while writing stable
Pulkit Goyal <pulkit@yandex-team.ru> [Fri, 19 Apr 2019 23:13:28 +0300] rev 42173
branchcache: don't verify all nodes while writing nodes are verified either when they are added or used. In case of commits. we will load the whole branchmap, only verify nodes for the branch on which we are committing and then we write. However before this patch, writing the branchmap was validating all the nodes whereas it should not. This patch fixes that. Differential Revision: https://phab.mercurial-scm.org/D6290
Sat, 20 Apr 2019 07:29:07 -0700 setup: properly package distutils in py2exe virtualenv builds stable
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 20 Apr 2019 07:29:07 -0700] rev 42172
setup: properly package distutils in py2exe virtualenv builds Our in-repo py2exe packaging code uses virtualenvs for managing dependencies. An advantage of this is that packaging is more deterministic and reproducible. Without virtualenvs, we need to install packages in the system Python install. Packages installed by other consumers of the system Python could leak into the Mercurial package. A regression from this change was that py2exe packages contained the virtualenv's hacked distutils modules instead of the original distutils modules. (virtualenv installs a hacked distutils module because distutils uses relative path lookups that fail when running from a virtualenv.) This commit introduces a workaround so py2exe packaging uses the original distutils modules when running from a virtualenv. With this change, `import distutils` no longer fails from py2exe builds produced from a virtualenv. This fixes the regression. Furthermore, we now include all distutils modules. Before, py2exe's module finding would only find modules there were explicitly referenced in code. So, we now package a complete copy of distutils instead of a partial one. This is even better than before. # no-check-commit foo_bar function name
Wed, 17 Apr 2019 10:49:11 -0700 narrow: also warn when not deleting untracked or ignored files
Martin von Zweigbergk <martinvonz@google.com> [Wed, 17 Apr 2019 10:49:11 -0700] rev 42171
narrow: also warn when not deleting untracked or ignored files Differential Revision: https://phab.mercurial-scm.org/D6265
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip