Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Dec 2018 11:06:26 -0800] rev 42916
tests: split out manifest case from test-strip-cross.t
The manifest case was added on after the other cases, in d67cfe0d4714
(test-strip-cross: test handling of linkrev crosses in the manifest,
2008-01-20). I think it's easier to read and modify if it's separated.
Differential Revision: https://phab.mercurial-scm.org/D6792
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Dec 2018 11:09:05 -0800] rev 42915
tests: don't log manifest-file in test-strip-cross.t
I'm confident that the file is there only to help produce a certain
manifest log; there is nothing special about the file's filelog
itself. (And there already is a `hg debugindex --manifest` call higher
up in the file that shows the crossed linkrevs.)
Differential Revision: https://phab.mercurial-scm.org/D6791
Martin von Zweigbergk <martinvonz@google.com> [Mon, 17 Dec 2018 10:27:00 -0800] rev 42914
tests: use positive revision numbers in test-strip-cross.t
It took me a long time to realize that '-r -1' was pulling revision -1
because I didn't even notice the minus sign until I tried changing the
revision number. The order of arguments doesn't matter, so I changed
from decreasing order to increasing while at it.
Differential Revision: https://phab.mercurial-scm.org/D6790
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 05 Sep 2019 21:09:58 -0700] rev 42913
automation: implement "publish-windows-artifacts" command
The new command and associated functionality can be used to
automate the publishing of Windows release artifacts. It
supports uploading wheels to PyPI (using twine) and copying
the artifacts to mercurial-scm.org and updating the latest.dat
file to advertise them via the website.
I ran `automation.py publish-windows-artifacts 5.1.1` and it
appeared to "just work." But the real test will be to do this
on the next release...
Differential Revision: https://phab.mercurial-scm.org/D6786
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 05 Sep 2019 21:08:35 -0700] rev 42912
automation: upgrade to latest packages in requirements.txt
Let's stay modern.
Differential Revision: https://phab.mercurial-scm.org/D6785
Augie Fackler <augie@google.com> [Thu, 15 Aug 2019 14:53:27 -0400] rev 42911
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
Joerg Sonnenberger <joerg@bec.de> [Sat, 07 Sep 2019 12:49:33 +0200] rev 42910
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
Matt Harbison <matt_harbison@yahoo.com> [Sat, 07 Sep 2019 23:20:11 -0400] rev 42909
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
Matt Harbison <matt_harbison@yahoo.com> [Sat, 07 Sep 2019 13:44:29 -0400] rev 42908
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 17:50:04 +0100] rev 42907
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).
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 17:39:16 +0100] rev 42906
run-tests: remove the artificial indentation
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 17:37:04 +0100] rev 42905
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).
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Sep 2019 10:08:41 +0200] rev 42904
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).
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Sep 2019 09:42:53 +0200] rev 42903
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Sep 2019 01:02:34 +0200] rev 42902
sshserver: flush stream after command dispatch
I am not sure why this is not working as expected, but without this client might
not see some important output. Without this patch moving some output at
transaction closing time makes it disapear for ssh client in various sitaution.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Sep 2019 00:11:20 +0200] rev 42901
narrow: rely on setting `quiet` mode instead of `pushbuffer`
The `quiet` approach is what `shelve` uses and give the same result. This will
help us to add less code in future changesets.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 14 Oct 2018 12:59:02 +0200] rev 42900
transaction: issue "new obsmarkers" message at the end of the transaction
Instead of making bundle2 code responsible for this, it seems better to have it
handled and the transaction level. First, it means the message will be more
consistently printed. Second it means we won't spam the message over and over if
the data arrive in multiple piece. Third, we are planning to move other similar
message at the same level (for the same reason) so having them all at the same
location will help us to control the order they are displayed.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 14 Oct 2018 13:19:24 +0200] rev 42899
debugobsolete: also issue the "new obsmarkers" messsage
We are going to improve the way this message is issued in the core codebase.
This will make it appears for `hg debugobsolete` too. Since this seems like a
good idea, we make the output change in a previous changesets to clarify the
next changeset.
Yuya Nishihara <yuya@tcha.org> [Fri, 06 Sep 2019 08:32:48 +0900] rev 42898
split: use literal syntax to build a set of one element
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 13:23:55 +0900] rev 42897
rust-cpython: leverage py_shared_iterator::from_inner() where appropriate
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 13:08:59 +0900] rev 42896
rust-cpython: remove Option<_> from interface of py_shared_iterator
It's the implementation detail of the py_shared_iterator that the leaked
reference is kept in Option<_> so that it can be dropped early.
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 12:26:12 +0900] rev 42895
rust-cpython: rename py_shared_iterator_impl to py_shared_iterator
It's a public interface now.
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 12:23:18 +0900] rev 42894
rust-cpython: replace dyn Iterator<..> of mapping with concrete type
See the previous commit for why. The docstring is moved accordingly.
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 12:07:19 +0900] rev 42893
rust-cpython: replace dyn Iterator<..> of sequence with concrete type
We wouldn't care the cost of the dynamic dispatch, but I feel a concrete
type helps understanding error messages.