Thu, 05 Sep 2019 21:09:58 -0700 automation: implement "publish-windows-artifacts" command
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 05 Sep 2019 21:09:58 -0700] rev 42907
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
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.
Sun, 08 Sep 2019 01:02:34 +0200 sshserver: flush stream after command dispatch
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Sep 2019 01:02:34 +0200] rev 42896
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.
Sun, 08 Sep 2019 00:11:20 +0200 narrow: rely on setting `quiet` mode instead of `pushbuffer`
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 08 Sep 2019 00:11:20 +0200] rev 42895
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.
Sun, 14 Oct 2018 12:59:02 +0200 transaction: issue "new obsmarkers" message at the end of the transaction
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 14 Oct 2018 12:59:02 +0200] rev 42894
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.
Sun, 14 Oct 2018 13:19:24 +0200 debugobsolete: also issue the "new obsmarkers" messsage
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 14 Oct 2018 13:19:24 +0200] rev 42893
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.
Fri, 06 Sep 2019 08:32:48 +0900 split: use literal syntax to build a set of one element
Yuya Nishihara <yuya@tcha.org> [Fri, 06 Sep 2019 08:32:48 +0900] rev 42892
split: use literal syntax to build a set of one element
Sun, 08 Sep 2019 13:23:55 +0900 rust-cpython: leverage py_shared_iterator::from_inner() where appropriate
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 13:23:55 +0900] rev 42891
rust-cpython: leverage py_shared_iterator::from_inner() where appropriate
Sun, 08 Sep 2019 13:08:59 +0900 rust-cpython: remove Option<_> from interface of py_shared_iterator
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 13:08:59 +0900] rev 42890
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.
Sun, 08 Sep 2019 12:26:12 +0900 rust-cpython: rename py_shared_iterator_impl to py_shared_iterator
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 12:26:12 +0900] rev 42889
rust-cpython: rename py_shared_iterator_impl to py_shared_iterator It's a public interface now.
Sun, 08 Sep 2019 12:23:18 +0900 rust-cpython: replace dyn Iterator<..> of mapping with concrete type
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 12:23:18 +0900] rev 42888
rust-cpython: replace dyn Iterator<..> of mapping with concrete type See the previous commit for why. The docstring is moved accordingly.
Sun, 08 Sep 2019 12:07:19 +0900 rust-cpython: replace dyn Iterator<..> of sequence with concrete type
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 12:07:19 +0900] rev 42887
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.
Sun, 08 Sep 2019 12:00:26 +0900 rust-dirstate: provide CopyMapIter and StateMapIter types
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 12:00:26 +0900] rev 42886
rust-dirstate: provide CopyMapIter and StateMapIter types They will be used in the declaration of Python iterator types.
Sun, 08 Sep 2019 11:55:29 +0900 rust-dirstate: specify concrete return type of DirsMultiset::iter()
Yuya Nishihara <yuya@tcha.org> [Sun, 08 Sep 2019 11:55:29 +0900] rev 42885
rust-dirstate: specify concrete return type of DirsMultiset::iter() This allows us to put a returned iterator in a struct. We could implement DirsMultisetIter(hash_map::Keys<..>) struct to hide the implementation detail, but I think type alias is good enough for us.
Sat, 27 Apr 2019 02:04:05 +0200 discovery: replace "heads" by "changesets" in a output note (BC)
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 27 Apr 2019 02:04:05 +0200] rev 42884
discovery: replace "heads" by "changesets" in a output note (BC) When using `hg push --rev X`, the subset considered by discovery is only `::X`. In addition, `X` can be any local revisions not just local heads. As a result the message "all local heads known locally" can be misleading. We replace it with the more accurate "all local changesets known remotely". The message appears when in verbose not, so this is stricly speaking a BC breakage. I am not sure this would be a real issue in practice...
Thu, 05 Sep 2019 16:32:33 -0700 py3: drop incorrect fsencode(findexe(...)) in procutil
Martin von Zweigbergk <martinvonz@google.com> [Thu, 05 Sep 2019 16:32:33 -0700] rev 42883
py3: drop incorrect fsencode(findexe(...)) in procutil I recently added the bad call, thinking that findexe() was a standard library function returning a string result, but it's actually our own function returning bytes. Thanks to Yuya for noticing. Differential Revision: https://phab.mercurial-scm.org/D6826
Sat, 07 Sep 2019 10:08:47 -0700 flagprocessors: small code update to clarify parameters
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 07 Sep 2019 10:08:47 -0700] rev 42882
flagprocessors: small code update to clarify parameters 'raw' is really a third mode, not a small variant. Differential Revision: https://phab.mercurial-scm.org/D6807
Sat, 07 Sep 2019 10:06:32 -0700 flagprocessors: deprecate _processflags
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 07 Sep 2019 10:06:32 -0700] rev 42881
flagprocessors: deprecate _processflags People should use the specialized version instead now. Differential Revision: https://phab.mercurial-scm.org/D6806
Mon, 02 Sep 2019 17:06:15 +0200 simplestorerepo: stop using `_processflags` directly
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 02 Sep 2019 17:06:15 +0200] rev 42880
simplestorerepo: stop using `_processflags` directly We now use the specialized versions. Differential Revision: https://phab.mercurial-scm.org/D6805
Mon, 02 Sep 2019 17:05:52 +0200 revlog: stop using `_processflags` directly
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 02 Sep 2019 17:05:52 +0200] rev 42879
revlog: stop using `_processflags` directly We now use the specialized versions. Differential Revision: https://phab.mercurial-scm.org/D6804
Fri, 30 Aug 2019 19:13:12 +0200 flagprocessors: use _processflagsraw in easy cases
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 30 Aug 2019 19:13:12 +0200] rev 42878
flagprocessors: use _processflagsraw in easy cases When there are no ambiguity regarding the `raw` value, we can simply use the new method. Differential Revision: https://phab.mercurial-scm.org/D6803
Fri, 30 Aug 2019 19:10:15 +0200 flagprocessors: use _processflagsread in simple cases
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 30 Aug 2019 19:10:15 +0200] rev 42877
flagprocessors: use _processflagsread in simple cases When there are no ambiguity regarding the `raw` value, we can simply use the new method. Differential Revision: https://phab.mercurial-scm.org/D6802
Fri, 30 Aug 2019 19:07:49 +0200 flagprocessors: use _processflagswrite for write operation
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 30 Aug 2019 19:07:49 +0200] rev 42876
flagprocessors: use _processflagswrite for write operation There are no ambiguity for 'write' operation so it is simple to replace. Differential Revision: https://phab.mercurial-scm.org/D6801
Fri, 30 Aug 2019 18:54:36 +0200 flagprocessors: introduce specialized functions
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 30 Aug 2019 18:54:36 +0200] rev 42875
flagprocessors: introduce specialized functions This make the call site clearer and the open the way to more diverse return types. For now, the same old code is still in use under the hood. Differential Revision: https://phab.mercurial-scm.org/D6800
Thu, 08 Aug 2019 02:10:18 +0200 flagutil: use it in simplestorerepo
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 02:10:18 +0200] rev 42874
flagutil: use it in simplestorerepo This remove the other code duplication of the `_processflags` code. To be honest, this code looks very dead since it is not run by either developer nor buildbot. However, we update the code to make the task of reviving this less daunting. Differential Revision: https://phab.mercurial-scm.org/D6799
Thu, 08 Aug 2019 01:15:44 +0200 flagutil: make the error class used by the mixin configurable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 01:15:44 +0200] rev 42873
flagutil: make the error class used by the mixin configurable One of the code duplication use a different error class. So let's make it possible to do so. Differential Revision: https://phab.mercurial-scm.org/D6798
Sat, 07 Sep 2019 09:56:45 -0700 flagutil: use the new mixin use in remotefilelog
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 07 Sep 2019 09:56:45 -0700] rev 42872
flagutil: use the new mixin use in remotefilelog This remove one of the code duplication. Hooray \o/. Differential Revision: https://phab.mercurial-scm.org/D6797
Thu, 08 Aug 2019 01:12:48 +0200 flagutil: introduce a flagprocessorsmixin class
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 08 Aug 2019 01:12:48 +0200] rev 42871
flagutil: introduce a flagprocessorsmixin class To avoid code duplication, we will provide a simple "ready to use" mixin that carry the appropriate logic. First we use it in standard revlog, we'll remove code duplication in later changesets. Differential Revision: https://phab.mercurial-scm.org/D6796
Fri, 06 Sep 2019 23:26:30 -0700 check-code: allow command substitution with $(command)
Martin von Zweigbergk <martinvonz@google.com> [Fri, 06 Sep 2019 23:26:30 -0700] rev 42870
check-code: allow command substitution with $(command) Both `command` and $(command) are specified by POSIX. The latter nests better. I don't see why we shouldn't allow both (or only the latter). Differential Revision: https://phab.mercurial-scm.org/D6789
Fri, 14 Jun 2019 16:26:11 +0100 run-tests: rename `lcmd` variable to `line_cmd`
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 16:26:11 +0100] rev 42869
run-tests: rename `lcmd` variable to `line_cmd` This is clearer and more in line with some other variable names. (This is a gratuitous cleanup that I made while investigating a bug).
Fri, 14 Jun 2019 16:24:34 +0100 run-tests: rename `lout` variable to `out_line`
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 16:24:34 +0100] rev 42868
run-tests: rename `lout` variable to `out_line` This is clearer and more in line with some other variable names. (This is a gratuitous cleanup that I made while investigating a bug).
Fri, 14 Jun 2019 14:14:17 +0100 run-tests: clarify "l" variable as "out_rawline"
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 14:14:17 +0100] rev 42867
run-tests: clarify "l" variable as "out_rawline" More explicit variable name never hurt. (This is a gratuitous cleanup that I made while investigating a bug).
Fri, 14 Jun 2019 13:59:47 +0100 run-tests: use symbolic constant instead of arbitrary number line matching
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 14 Jun 2019 13:59:47 +0100] rev 42866
run-tests: use symbolic constant instead of arbitrary number line matching (This is a gratuitous cleanup that I made while investigating a bug).
Sun, 25 Aug 2019 23:40:22 -0400 rustfilepatterns: shorter code for concatenating slices
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 25 Aug 2019 23:40:22 -0400] rev 42865
rustfilepatterns: shorter code for concatenating slices Differential Revision: https://phab.mercurial-scm.org/D6765
Sun, 25 Aug 2019 22:53:42 -0400 match: simplify the regexps created for glob patterns
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 25 Aug 2019 22:53:42 -0400] rev 42864
match: simplify the regexps created for glob patterns For legibility of the resulting regexes, although it may help with performance as well. Differential Revision: https://phab.mercurial-scm.org/D6764
Mon, 26 Aug 2019 08:25:01 -0400 rustfilepatterns: refactor the pattern of removing a prefix from a &[u8]
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 26 Aug 2019 08:25:01 -0400] rev 42863
rustfilepatterns: refactor the pattern of removing a prefix from a &[u8] Differential Revision: https://phab.mercurial-scm.org/D6766
Sun, 25 Aug 2019 22:52:36 -0400 tests: show the pattern generated for a relative glob
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Sun, 25 Aug 2019 22:52:36 -0400] rev 42862
tests: show the pattern generated for a relative glob Differential Revision: https://phab.mercurial-scm.org/D6763
Tue, 16 Jul 2019 21:15:39 -0700 copies: remove existing copy info from the changeset on amend (BC)
Martin von Zweigbergk <martinvonz@google.com> [Tue, 16 Jul 2019 21:15:39 -0700] rev 42861
copies: remove existing copy info from the changeset on amend (BC) When amending a changeset with copy information in the changeset and the new changeset doesn't have any copy information (or similar for "filesadded" and "filesremoved"), we shouldn't keep it. A drawback of this is that we now unconditionally remove these four entries from the extras, breaking any extensions that happened to write entries with the same names (which seems very unlikely). I think I'd heard that there was list of blacklisted keys that would be removed from the extras when a commit is rewritten, but I couldn't find that. It would make sense to add the keys mentioned above there instead of the custom filtering I've added in this patch. Differential Revision: https://phab.mercurial-scm.org/D6752
Tue, 16 Jul 2019 21:15:35 -0700 tests: show invalid copies when turning off copies-in-changeset
Martin von Zweigbergk <martinvonz@google.com> [Tue, 16 Jul 2019 21:15:35 -0700] rev 42860
tests: show invalid copies when turning off copies-in-changeset If you turn on copies in changesets and write a commit with a copy, then turn it off and amend the commit while undoing the copy, the invalid copy information will remain. The read path doesn't crash in invalid copy data, but it seems better to not produce the invalid data. Differential Revision: https://phab.mercurial-scm.org/D6751
Mon, 19 Aug 2019 15:43:27 -0700 context: filter out invalid copies from workingctx.p[12]copies()
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Aug 2019 15:43:27 -0700] rev 42859
context: filter out invalid copies from workingctx.p[12]copies() workingctx normally gets its lists of modified, added, removed files etc. based on the dirstate status. Its constructor also accepts a "changes" argument to override the status from the dirstate. This is used for partial commits. If a "changed" argument was passed, we should clearly also filter out copies to those paths, which I had previously missed. This patch adds that filtering and fixes the bugs demonstrated in the previous patch. Differential Revision: https://phab.mercurial-scm.org/D6750
Mon, 19 Aug 2019 12:30:02 -0700 tests: demonstrate crash when committing subset of copies to changeset
Martin von Zweigbergk <martinvonz@google.com> [Mon, 19 Aug 2019 12:30:02 -0700] rev 42858
tests: demonstrate crash when committing subset of copies to changeset When writing copy metadata to the changeset and not committing all copies in the dirstate, we get a ProgrammingError. This commit adds two tests showing how to trigger this bug. Differential Revision: https://phab.mercurial-scm.org/D6749
Thu, 22 Aug 2019 20:36:13 +0300 bdiff-torture: fix pyflakes warning reporting undefined name 'inst'
Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 22 Aug 2019 20:36:13 +0300] rev 42857
bdiff-torture: fix pyflakes warning reporting undefined name 'inst' Looks like I got a latest version of pyflakes somehow or it's running on py3 and it spotted this. Differential Revision: https://phab.mercurial-scm.org/D6757
Tue, 27 Aug 2019 11:56:19 -0700 split: handle partial commit of renames when doing split or record (issue5723)
Kyle Lippincott <spectral@google.com> [Tue, 27 Aug 2019 11:56:19 -0700] rev 42856
split: handle partial commit of renames when doing split or record (issue5723) When using split or record, using either interface (text or curses), selecting portions of the file to be committed/recorded did not work; the entire file was treated as having been selected. This was because the logic for handling partial application of the patches relies on knowing what files are "new with modifications" and it doesn't treat "rename destination" as "new". There was a complicating issue, however. We're relying on the patch header specifying the copy from/to information, which works as long as the 'copy from' file is there. In the case of renames, however, the 'rename from' file is *not* there, so we need to add it back. Differential Revision: https://phab.mercurial-scm.org/D6768
Tue, 27 Aug 2019 11:56:15 -0700 split: handle partial commit of copies when doing split or record
Kyle Lippincott <spectral@google.com> [Tue, 27 Aug 2019 11:56:15 -0700] rev 42855
split: handle partial commit of copies when doing split or record When using split or record, using either interface (text or curses), selecting portions of the file to be committed/recorded did not work; the entire file was treated as having been selected. This appears to be because the logic for handling partial application of the patches relies on knowing what files are "new with modifications", and it doesn't treat "copy destination" as "new". Handling renames correctly is more difficult and will be done in a later patch. Differential Revision: https://phab.mercurial-scm.org/D6767
Sun, 01 Sep 2019 23:43:59 -0700 py3: use pycompat.sysargv[0] for instead of fsencode(sys.argv[0])
Martin von Zweigbergk <martinvonz@google.com> [Sun, 01 Sep 2019 23:43:59 -0700] rev 42854
py3: use pycompat.sysargv[0] for instead of fsencode(sys.argv[0]) Yuya noted in a recent review that fsencode(sys.argv[0]) could be incorrect on Windows. Differential Revision: https://phab.mercurial-scm.org/D6782
Wed, 04 Sep 2019 14:35:39 -0700 httppeer: use context manager when reading temporary bundle to send
Martin von Zweigbergk <martinvonz@google.com> [Wed, 04 Sep 2019 14:35:39 -0700] rev 42853
httppeer: use context manager when reading temporary bundle to send Differential Revision: https://phab.mercurial-scm.org/D6784
Wed, 04 Sep 2019 10:42:26 -0700 httppeer: use context manager when writing temporary bundle to send
Martin von Zweigbergk <martinvonz@google.com> [Wed, 04 Sep 2019 10:42:26 -0700] rev 42852
httppeer: use context manager when writing temporary bundle to send Differential Revision: https://phab.mercurial-scm.org/D6783
Sun, 01 Sep 2019 18:06:31 +0900 rust-cpython: mark unsafe functions as such
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Sep 2019 18:06:31 +0900] rev 42851
rust-cpython: mark unsafe functions as such It wasn't trivial to fix leak_immutable() to be safe since we have to allow immutable operations (e.g. iter()) on the leaked reference. So let's mark it unsafe for now. Callers must take care of the returned object to guarantee the memory safety. I'll revisit this later. I think $leaked<T: 'static> could have a function that converts itself into $leaked<U: 'static> with a given FnOnce(&T) -> &U, where T is $inner_struct, and U is $iterator_type for example.
Sun, 01 Sep 2019 17:48:24 +0900 rust-cpython: pair leaked reference with its manager object
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Sep 2019 17:48:24 +0900] rev 42850
rust-cpython: pair leaked reference with its manager object Still leak_immutable() is unsafe since leak_handle must live longer than the leaked_ref.
Sun, 01 Sep 2019 17:37:30 +0900 rust-cpython: introduce restricted variant of RefCell
Yuya Nishihara <yuya@tcha.org> [Sun, 01 Sep 2019 17:37:30 +0900] rev 42849
rust-cpython: introduce restricted variant of RefCell This should catch invalid borrow_mut() calls. Still the ref-sharing interface is unsafe.
Sat, 07 Sep 2019 14:51:18 +0200 tests: register test-merge-combination.t as small but slow stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 07 Sep 2019 14:51:18 +0200] rev 42848
tests: register test-merge-combination.t as small but slow run-tests.py use file size as an heuristic for test run time. The new `test-merge-combination.t` is a small file that do a lot of processing. As a result it tend to be scheduled really late but delay the full test run by a lot. On an example test run, the one-before-last test completed 279s after the start of the run, while `test-merge-combination.t` finished 355s after it. A 76s delay. This delay can be avoided since `test-merge-combination.t` only got started 175s after the start of the run.
(0) -30000 -10000 -3000 -1000 -300 -100 -60 +60 +100 +300 +1000 +3000 tip