Thu, 05 Sep 2019 21:08:35 -0700 automation: upgrade to latest packages in requirements.txt
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 05 Sep 2019 21:08:35 -0700] rev 42906
automation: upgrade to latest packages in requirements.txt Let's stay modern. Differential Revision: https://phab.mercurial-scm.org/D6785
Thu, 15 Aug 2019 14:53:27 -0400 localrepo: push manifestlog and changelog construction code into store
Augie Fackler <augie@google.com> [Thu, 15 Aug 2019 14:53:27 -0400] rev 42905
localrepo: push manifestlog and changelog construction code into store This feels substantially more appropriate, as the store is actually the layer with knowledge of how to handle this storage. I didn't move the caching decorators for now because that's going to require some more involved work, and this unblocks my current experimentation. Differential Revision: https://phab.mercurial-scm.org/D6732
Sat, 07 Sep 2019 12:49:33 +0200 notify: add option for deterministic message-id generation
Joerg Sonnenberger <joerg@bec.de> [Sat, 07 Sep 2019 12:49:33 +0200] rev 42904
notify: add option for deterministic message-id generation Copied from email by durin42: > Pierre-Yves asked offline why I asked a new option for this and why it > is not the default. Message-Id is supposed to be unique world-wide and > while it is desirable to have a deterministic mechanism for them for > creating follow-up emails, it needs organisational control for ensuring > the uniqueness. Differential Revision: https://phab.mercurial-scm.org/D6824
Sat, 07 Sep 2019 23:20:11 -0400 uncommit: add options to update to the current user or current date
Matt Harbison <matt_harbison@yahoo.com> [Sat, 07 Sep 2019 23:20:11 -0400] rev 42903
uncommit: add options to update to the current user or current date These are also from the evolve extension's version of uncommit. I tried adding validation that both forms of user or date can't be specified at the same time, but that fails because these show up in `opts` with a None value whether or not the option was given on the command line. Presumably that means the conditional in `resolvecommitoptions` could be simplified. But this is how both evolve and MQ handle it. Differential Revision: https://phab.mercurial-scm.org/D6828
Sat, 07 Sep 2019 13:44:29 -0400 uncommit: add support to modify the commit message and date
Matt Harbison <matt_harbison@yahoo.com> [Sat, 07 Sep 2019 13:44:29 -0400] rev 42902
uncommit: add support to modify the commit message and date Currently, the evolve extension's version of this command supports it. Differential Revision: https://phab.mercurial-scm.org/D6827
Fri, 14 Jun 2019 17:50:04 +0100 run-tests: add a dedicated 'isoptional' function
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 17:50:04 +0100] rev 42901
run-tests: add a dedicated 'isoptional' function This is clearer than repeated manual call to to 'endswith'. (This is a gratuitous cleanup that I made while investigating a bug).
Fri, 14 Jun 2019 17:39:16 +0100 run-tests: remove the artificial indentation
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 17:39:16 +0100] rev 42900
run-tests: remove the artificial indentation
Fri, 14 Jun 2019 17:37:04 +0100 run-tests: extract a `process_out_line` from the main function
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 17:37:04 +0100] rev 42899
run-tests: extract a `process_out_line` from the main function The main function doing line comparison is quite complex. Slicing it in smaller piece should clarify it. To avoid a huge diff, the code is kept at the same indentation. We'll re-indent in the next changesets. (This is a gratuitous cleanup that I made while investigating a bug).
Sun, 08 Sep 2019 10:08:41 +0200 run-tests: extract a `process_cmd_line` from the main function
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Sep 2019 10:08:41 +0200] rev 42898
run-tests: extract a `process_cmd_line` from the main function The main function doing line comparison is quite complex. Slicing it in smaller piece should clarify it. (This is a gratuitous cleanup that I made while investigating a bug).
Sun, 08 Sep 2019 09:42:53 +0200 changegroup: move message about added changes to transaction summary
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Sep 2019 09:42:53 +0200] rev 42897
changegroup: move message about added changes to transaction summary Before that, applying multiple changegroups in the same transaction issued the message multiple time. This result in a confusing output: adding changesets adding manifests adding file changes added 32768 changesets with 60829 changes to 2668 files adding changesets adding manifests adding file changes added 8192 changesets with 16885 changes to 1553 files adding changesets adding manifests adding file changes added 1020 changesets with 1799 changes to 536 files adding changesets adding manifests ... Instead, we now only issue the message once at the end of the transaction, summing up all added changesets, changes and files. The line is identical, but happens sightly later in the output. There are other suboptimal behavior around issue multiple changegroup (eg: progress bar). We'll cover them later. This impact of lot of test as one would expect, but a two pass check show they are just the order change we expected. To deal with "under the hood" bundle application by internal code, we had to take a slightly hacky move. We could clean that up with a more official way to enter "under the hood" section, however I want to keep this series simple to get it landed. This kind of change have a very high bit rot rate since it impact a lot of test output.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip