Fri, 22 Nov 2019 10:39:05 +0100 rust-dirs: address failing tests for `dirs` impl with a temporary fix
Raphaël Gomès <rgomes@octobus.net> [Fri, 22 Nov 2019 10:39:05 +0100] rev 43788
rust-dirs: address failing tests for `dirs` impl with a temporary fix https://phab.mercurial-scm.org/D7252 (5d40317d42b7083b49467502549e25f144888cb3) introduced a regression in Rust tests. This is a temporary fix that replicates the behavior of the C and Python impl, pending the resolution of the discussion (in the phabricator link) about how we actually want to solve this problem. Differential Revision: https://phab.mercurial-scm.org/D7503
Sun, 01 Dec 2019 18:46:10 -0500 cleanup: fix docstring formatting
Matt Harbison <matt_harbison@yahoo.com> [Sun, 01 Dec 2019 18:46:10 -0500] rev 43787
cleanup: fix docstring formatting This is just removing the b'' prefix (except demandimportpy2), and making sure it is triple quoted. I skipped the mapping.py module in zope because that's 3rd party code. Differential Revision: https://phab.mercurial-scm.org/D7539
Wed, 13 Nov 2019 20:42:13 +0100 copies: split the combination of the copies mapping in its own function
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Nov 2019 20:42:13 +0100] rev 43786
copies: split the combination of the copies mapping in its own function In some case, this part take up to 95% of the copy tracing that take about a hundred second. This poor performance comes from the fact we keep duplciating and merging dictionary that are mostly similar. I want to experiment with smarter native code to do this, so I need to isolate the function first.
Wed, 13 Nov 2019 09:39:44 +0100 copies: do not initialize the dictionary with root in changeset copies
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Nov 2019 09:39:44 +0100] rev 43785
copies: do not initialize the dictionary with root in changeset copies We don't strictly need the dict to be prefiled with `{}`. Not doing so will make the next changeset simpler. This part of a preparation to use native code for this part of copy tracing.
Wed, 13 Nov 2019 20:42:08 +0100 copies: expand `_chain` variable name to make the function easier to read
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Nov 2019 20:42:08 +0100] rev 43784
copies: expand `_chain` variable name to make the function easier to read This came up while explaining what the function is about. I find the function easier to follow that way.
Wed, 13 Nov 2019 20:45:34 +0100 copies: show we can read data from the "first" mapping
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Nov 2019 20:45:34 +0100] rev 43783
copies: show we can read data from the "first" mapping In practice this make no difference since `t` is a copy of `a`. Having this change before hand will make the next cleanup changeset clearer. This is work on the road to using some native code for some performance critical part of copy tracing.
Wed, 13 Nov 2019 20:33:22 +0100 copies: return consistent type from revinfo
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 13 Nov 2019 20:33:22 +0100] rev 43782
copies: return consistent type from revinfo The return is expected to be a list, so we should return a list. This make the use of this function from type-checked language (eg: rust) much simpler.
Mon, 25 Nov 2019 12:44:04 -0800 dateutil: correct default for Ymd in parsedate
Jun Wu <quark@fb.com> [Mon, 25 Nov 2019 12:44:04 -0800] rev 43781
dateutil: correct default for Ymd in parsedate The code uses `0` for the default value of Ymd (year, month, and day), which seems suboptimal. For example, these will fail to parse: dateutil.parsedate('2000', formats=dateutil.extendeddateformats) dateutil.parsedate('Jan 2000', formats=dateutil.extendeddateformats) Fix it by providing sane defaults (1 instead of 0) for year, month, and day. The suboptimal behavior was introduced by 91bc001a592 (2010-12-29, "date: fix matching of underspecified date ranges"), which does not seem to justify the current behavior. Note end-users should not notice the subtle issue, because there are no formats in `defaultdateformats` that allow an explicit year with omitted month, or an explicit month with omitted day. Differential Revision: https://phab.mercurial-scm.org/D7520
Mon, 25 Nov 2019 12:33:06 -0800 test-doctest: include dateutil
Jun Wu <quark@fb.com> [Mon, 25 Nov 2019 12:33:06 -0800] rev 43780
test-doctest: include dateutil `mercurial.utils.dateutil` has dostrings that contain doctests. Include them. Differential Revision: https://phab.mercurial-scm.org/D7519
Mon, 25 Nov 2019 11:53:50 -0800 revlog: fix revset in reachableroots docstring
Jun Wu <quark@fb.com> [Mon, 25 Nov 2019 11:53:50 -0800] rev 43779
revlog: fix revset in reachableroots docstring `reachableroots` will only return a subset of `roots` when `includepath` is False. For example, given the following linear DAG: 2 | 1 | 0 Using roots=0+2, heads=1, the definition in the docstring does not match what `reachableroots` actually does: ipdb> repo.changelog.reachableroots(0, roots=[0,2],heads=[1]) [0] ipdb> repo.revs('heads(::(0+2) & (0+2)::1)') <baseset+ [1]> The fix is to do `heads & ::roots` (or `heads & heads::roots`) first, then select their ancestors: ipdb> repo.revs('heads(::((0+2) & (0+2)::1))') <baseset+ [0]> The docstring was introduced by fd92bfbbe02d9 (2015-06-19 "revset: rename revsbetween to reachableroots and add an argument"), which introduced the `includepath=False` behavior for graphlog grandparents use-case. I believe the docstring instead of the code should be changed because changing the code to match the docstring can result in suboptimal graphlog like: o :\ : o : : :/ o As opposite to the current "linearized" graphlog: o | o : o Differential Revision: https://phab.mercurial-scm.org/D7518
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip