Fri, 02 Nov 2018 14:18:26 -0400 Added tag 4.8 for changeset a91a2837150b stable
Augie Fackler <raf@durin42.com> [Fri, 02 Nov 2018 14:18:26 -0400] rev 40429
Added tag 4.8 for changeset a91a2837150b
Sun, 28 Oct 2018 21:16:36 +0900 rust: fix signature of rustlazyancestors_init() function stable 4.8
Yuya Nishihara <yuya@tcha.org> [Sun, 28 Oct 2018 21:16:36 +0900] rev 40428
rust: fix signature of rustlazyancestors_init() function Obviously, sizeof(int) != mem::size_of::<usize>() on amd64, though the argument would be passed in 64-bit register anyway.
Fri, 02 Nov 2018 21:25:35 +0900 tests: require SQLite 3.8.3+ as sqlitestore relies on "WITH" clause stable
Yuya Nishihara <yuya@tcha.org> [Fri, 02 Nov 2018 21:25:35 +0900] rev 40427
tests: require SQLite 3.8.3+ as sqlitestore relies on "WITH" clause The test fails on gcc112 because the SQLite is too old. https://sqlite.org/changes.html#version_3_8_3
Fri, 19 Oct 2018 22:09:53 +0800 relnotes: various tweaks for release notes stable
Anton Shestakov <av6@dwimlabs.net> [Fri, 19 Oct 2018 22:09:53 +0800] rev 40426
relnotes: various tweaks for release notes Stop filtering out commits that are expected to be covered by releasenotes extension: now we want two lists, one for WhatsNew and one for ReleaseX.Y. Use `only(stoprev, startrev)` to make `relnotes -h` output be actually true about what revisions are included. More filter rules, mostly obvious. More classifying rules to have less things in "unsorted". Looks like nargs=1 was just making args.startrev and args.stoprev be lists for no reason. BC and API sections are renamed to what we're using on the WhatsNew page, and also just skipped if empty.
Thu, 01 Nov 2018 12:52:16 +0100 delta: skip "empty delta" optimisation for non-general case (issue6006) stable
Boris Feld <boris.feld@octobus.net> [Thu, 01 Nov 2018 12:52:16 +0100] rev 40425
delta: skip "empty delta" optimisation for non-general case (issue6006) Non-general delta repository cannot delta against anything than prev. So even if the delta to prev is empty we should use it. This is similar to the change made in bafa1c4bb7a8. Differential Revision: https://phab.mercurial-scm.org/D5201
Thu, 01 Nov 2018 16:32:16 -0700 narrow: fix copies._fullcopytracing() narrowspec filtering in graft case stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 01 Nov 2018 16:32:16 -0700] rev 40424
narrow: fix copies._fullcopytracing() narrowspec filtering in graft case I broke this too in 707c3804e607 (narrow: move copies overrides to core, 2018-09-28). Hopefully I'm done fixing things broken by that commit now. Differential Revision: https://phab.mercurial-scm.org/D5213
Thu, 01 Nov 2018 16:28:11 -0700 tests: demonstrate broken copies._fullcopytracing() stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 01 Nov 2018 16:28:11 -0700] rev 40423
tests: demonstrate broken copies._fullcopytracing() Turns out copies._fullcopytracing() was also broken. Differential Revision: https://phab.mercurial-scm.org/D5212
Thu, 01 Nov 2018 13:20:12 -0700 narrow: make copies.pathcopies() filter with narrowspec again stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 01 Nov 2018 13:20:12 -0700] rev 40422
narrow: make copies.pathcopies() filter with narrowspec again I broke this in 707c3804e607 (narrow: move copies overrides to core, 2018-09-28). Differential Revision: https://phab.mercurial-scm.org/D5203
Thu, 01 Nov 2018 11:24:45 -0700 tests: demonstrate broken copies.pathcopies() stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 01 Nov 2018 11:24:45 -0700] rev 40421
tests: demonstrate broken copies.pathcopies() Differential Revision: https://phab.mercurial-scm.org/D5202
Wed, 31 Oct 2018 20:32:42 +0100 setup: explain to distutils how we write rc versions stable
"Paul Morelle <paul.morelle@octobus.net" [Wed, 31 Oct 2018 20:32:42 +0100] rev 40420
setup: explain to distutils how we write rc versions When we use a rc version number (e.g. 4.8rc0), bdist_msi is using distutils.StrictVersion to parse it into a tuple of numbers. By default, StrictVersion.version_re only recognizes [ab] for alpha/beta, where mercurial may use '-rc' or 'rc'. This change makes StrictVersion parse correctly our version numbers, so that bdist_msi doesn't fail on rc versions.
Wed, 31 Oct 2018 12:08:37 -0700 changegroup: restore default node ordering (issue6001) stable
Boris Feld <boris.feld@octobus.net> [Wed, 31 Oct 2018 12:08:37 -0700] rev 40419
changegroup: restore default node ordering (issue6001) Changeset db5501d9 changed the default node ordering from "storage" to "linearize". While the new API is more explicit and cleaner, the "linearize" order is problematic on certain repositories like netbeans where it makes bundling slower the more nodes we bundle. Pushing and pulling 100 changesets was ~20% slower and pushing and pulling 1000 changesets was ~600% slower. A very quick analysis of profile traces showed that the pull operation was taking more time creating the delta. Putting back the old default order seems to be the safe option. With more time during the next cycle, we can understand better the impact of sorting with the DAG order by default, the source of the regression and how to mitigate it. /!\ We are still waiting for the full performance impact but with this patch, bundling and pulling locally (not on the performance workstation) 1000 changesets on the netbeans repository is as fast as before the regression. Differential Revision: https://phab.mercurial-scm.org/D5196
Mon, 29 Oct 2018 17:26:25 +0100 changegroup: introduce an explicit linear sorting stable
Boris Feld <boris.feld@octobus.net> [Mon, 29 Oct 2018 17:26:25 +0100] rev 40418
changegroup: introduce an explicit linear sorting We still need to linearize the revisions in some cases, introduce an explicit `linear` sorting before changing back the default order. Differential Revision: https://phab.mercurial-scm.org/D5195
Wed, 31 Oct 2018 21:16:54 +0900 fix: disable use of thread-based worker stable
Yuya Nishihara <yuya@tcha.org> [Wed, 31 Oct 2018 21:16:54 +0900] rev 40417
fix: disable use of thread-based worker getfixes() accesses to repo, changectx, filectx, etc., so I believe there are code paths triggering data race. Mercurial API isn't thread safe in general.
Wed, 31 Oct 2018 15:27:06 +0300 configitems: rename the config to prevent adding an alias in future stable
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 31 Oct 2018 15:27:06 +0300] rev 40416
configitems: rename the config to prevent adding an alias in future Right now the config option looks like: [experimental.server] stream-narrow-clones= which does not match how config options are generally defined in core. So let's rename this to: [experimental] server.stream-narrow-clones= before the new release so that we don't have to add an alias in future for this. Differential Revision: https://phab.mercurial-scm.org/D5198
Wed, 31 Oct 2018 11:02:08 +0100 sparse-revlog: only refine delta candidates in the sparse case (issue6006) stable
Boris Feld <boris.feld@octobus.net> [Wed, 31 Oct 2018 11:02:08 +0100] rev 40415
sparse-revlog: only refine delta candidates in the sparse case (issue6006) Starting with 5aef5afa8654, a valid delta parent might be "refined". This allows repository using sparse-revlog to produce better delta chain by using better intermediate snapshot base. However, this refining step was performed in all cases, including for repository not using sparse-revlog. This could produce a strange chain in the general delta case and corrupted repository in the non-general delta case. We now skip this step unless sparse-revlog is in use. In issue 6006, Yuya Nishihara provided a test case using an external repository, so we did not include it. Finding "laboratory" condition to reproduce this case and implementing an efficient test reproducing it is a bit tricky. We do not foresee to have the time to provide one by the release date. Differential Revision: https://phab.mercurial-scm.org/D5197
Mon, 29 Oct 2018 16:23:42 -0400 http: work around custom http client classes that refuse extra attrs stable
Augie Fackler <augie@google.com> [Mon, 29 Oct 2018 16:23:42 -0400] rev 40414
http: work around custom http client classes that refuse extra attrs I have no idea what is going on with our custom http client code at Google, but it chokes on these extra attributes we're tucking on http clients. Since it feels more than a little wrong to just stuff extra data on a client, let's degrade gracefully when the client class refuses the attributes.
Thu, 25 Oct 2018 21:33:43 +0800 crecord: make nextsametype() check that parent item exists (issue6009) stable
Anton Shestakov <av6@dwimlabs.net> [Thu, 25 Oct 2018 21:33:43 +0800] rev 40413
crecord: make nextsametype() check that parent item exists (issue6009) Items that represent files in curses interface don't have parents.
Wed, 24 Oct 2018 10:05:13 -0400 help: describe what ui.tweakdefaults changes, concretely stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 24 Oct 2018 10:05:13 -0400] rev 40412
help: describe what ui.tweakdefaults changes, concretely Currently, one has to look at the code. A couple things are suboptimal: - probably not translatable - lines don't get wrapped (a couple are a bit too long) but it seems to better this way than without help at all. Differential Revision: https://phab.mercurial-scm.org/D5187
Thu, 25 Oct 2018 00:22:42 -0400 logexchange: convert paths to unix when detecting the active path stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 25 Oct 2018 00:22:42 -0400] rev 40411
logexchange: convert paths to unix when detecting the active path This fixes the problem in the tests[1] where Windows was showing the whole path as the remotename for local repositories. Somebody with a better understanding of this extension should probably take a deeper look. There may be other cases that need to be converted- specifically the `elif not instance` and the missing `else` cases in activepath(). I also noticed when adding debug prints that the absolute path is stored in the file, probably not normalized. (It's wrapped up in $TESTTMP.) [1] https://buildbot.mercurial-scm.org/builders/Win7%20x86_64%20hg%20tests/builds/1042/steps/run-tests.py%20%28python%202.7.13%29/logs/stdio
Wed, 24 Oct 2018 22:40:48 -0400 help: update the default value specified for `profiling.time-track` stable
Matt Harbison <matt_harbison@yahoo.com> [Wed, 24 Oct 2018 22:40:48 -0400] rev 40410
help: update the default value specified for `profiling.time-track` I tried conditionalizing this in a `.. container::` block, but that seemed to add an extra blank line between the main text and the parenthetical.
Wed, 24 Oct 2018 22:24:10 -0400 profiling: revert the default mode back to 'cpu' on Windows stable
Matt Harbison <matt_harbison@yahoo.com> [Wed, 24 Oct 2018 22:24:10 -0400] rev 40409
profiling: revert the default mode back to 'cpu' on Windows On Windows, os.times() only returns user and system times. Real elapsed time is 0. That results in no actual times reported, an end wall time of 0.000000, and seemingly randomly sorted stack frames. This at least provides test stability in test-profile.t. I kind of think that `default=pycompat.iswindows and 'cpu' or 'real'` would be a better way to set the default in configitems, but I didn't see any other examples of this, and thought maybe there's a reason for that. That might allow plugging the value into the help text automatically- the documented default wasn't updated in db0dba2d157d.
Wed, 17 Oct 2018 14:47:01 +0200 phase: add an archived phase stable
Boris Feld <boris.feld@octobus.net> [Wed, 17 Oct 2018 14:47:01 +0200] rev 40408
phase: add an archived phase This phase allows for hidden changesets in the "user space". It differs from the "internal" phase which is intended for internal by-product only. There have been discussions at the 4.8 sprint to use such phase to speedup cleanup after history rewriting operation. Shipping it in the same release as the 'internal-phase' groups the associated `requires` entry. The important bit is to have support for this phase in the earliest version of mercurial possible. Adding the UI to manipulate this new phase later seems fine. The current plan for archived usage and user interface are as follow. On a repository with internal-phase on and evolution off: * history rewriting command set rewritten changeset in the archived phase. (This mean updating the cleanupnodes method). * keep `hg unbundle .hg/strip-backup/X.hg` as a way to restore changeset for now (backup bundle need to contains phase data) * [maybe] add a `hg strip --soft` advance flag (a light way to expose the feature without getting in the way of a better UI) Mercurial 4.8 freeze is too close to get the above in by then. We don't introduce a new repository `requirement` as we reuse the one introduced with the 'archived' phase during the 4.8 cycle.
Tue, 23 Oct 2018 20:46:21 +0900 exewrapper: apply clang-format to silence test-check-clang-format.t stable
Yuya Nishihara <yuya@tcha.org> [Tue, 23 Oct 2018 20:46:21 +0900] rev 40407
exewrapper: apply clang-format to silence test-check-clang-format.t
Mon, 22 Oct 2018 14:48:14 -0400 Added signature for changeset 956ec6f1320d stable
Augie Fackler <raf@durin42.com> [Mon, 22 Oct 2018 14:48:14 -0400] rev 40406
Added signature for changeset 956ec6f1320d
Mon, 22 Oct 2018 14:48:11 -0400 Added tag 4.8rc0 for changeset 956ec6f1320d stable
Augie Fackler <raf@durin42.com> [Mon, 22 Oct 2018 14:48:11 -0400] rev 40405
Added tag 4.8rc0 for changeset 956ec6f1320d
Mon, 22 Oct 2018 14:46:06 -0400 merge to stable for 4.8 release freeze stable 4.8rc0
Augie Fackler <augie@google.com> [Mon, 22 Oct 2018 14:46:06 -0400] rev 40404
merge to stable for 4.8 release freeze
Mon, 22 Oct 2018 11:34:35 -0700 shortest: never emit 0-length prefix even if unique
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Oct 2018 11:34:35 -0700] rev 40403
shortest: never emit 0-length prefix even if unique It turned out that the pure version of our code for finding the shortest unique nodeid prefix would return a 0-length string if that was unique (because there was at most one revision in the disambiguation set). That's kind of correct, but it can't be used as input, so we shouldn't return it. Let's just adjust the given minlength up to at least 1. This fixes test-template-functions.t, which was failing in pure mode. Differential Revision: https://phab.mercurial-scm.org/D5181
Mon, 22 Oct 2018 15:51:01 +0200 logtoprocess: sends the canonical command name to the subprocess
Boris Feld <boris.feld@octobus.net> [Mon, 22 Oct 2018 15:51:01 +0200] rev 40402
logtoprocess: sends the canonical command name to the subprocess One of the use-case of logtoprocess is to monitor command duration. With the current code, we only get whatever command name the user typed (either abbreviated or aliased). This makes analytics on the collected data more difficult. Stores the canonical command name in the request object. Pass the stored canonical name in the `req.ui.log("commandfinish", ...)` call as keyword argument to not break potential string formatting. Pass the value as the environment variable named `LTP_COMMAND` to the called script. Differential Revision: https://phab.mercurial-scm.org/D4820
Mon, 22 Oct 2018 15:47:30 +0200 logtoprocess: fix message formatting
Boris Feld <boris.feld@octobus.net> [Mon, 22 Oct 2018 15:47:30 +0200] rev 40401
logtoprocess: fix message formatting The logtoprocess used to try formatting the message using keyword options instead of always using the rest of the arguments. Update it to match blackbox behavior. Differential Revision: https://phab.mercurial-scm.org/D5180
Sat, 18 Aug 2018 01:44:38 +0200 profiling: move default mode to "real" time
Boris Feld <boris.feld@octobus.net> [Sat, 18 Aug 2018 01:44:38 +0200] rev 40400
profiling: move default mode to "real" time Mercurial operations involve a lot of disks or network access. These impact command runtime significantly and it seems important to report them in our default profiling output. Having the right default means that we don't forget them when asking people to produces profiling traces or when doing profiling ourselves. Moving to "real time" by default will remove the need to think about activating it on most occasions. The "CPU" time-based profiling is still accessible when necessary.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip