Thu, 01 Aug 2019 11:02:12 -0700 relnotes: copy "next" to "5.1" and clear "next" stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 01 Aug 2019 11:02:12 -0700] rev 42659
relnotes: copy "next" to "5.1" and clear "next" To avoid merge conflicts, we want to avoid modifying the file on multiple branches in parallel. This patch is therefore meant to be applied to the stable branch and then quickly be merged to default (at least before edits are made to relnotes/next there). Another option would have been to copy the file on the stable branch and to clear it on the default branch. However, that still results in conflicts if the copy is edited on the stable branch (Mercurial would try to apply the changes from the default branch to it). We could also delete the file in one commit and recreate it in another commit. However, Mercurial is quite inconsistent in what it considers a break in history (see test-copies-unrelated.t), so I'd like to avoid that. Differential Revision: https://phab.mercurial-scm.org/D6705
Sat, 03 Aug 2019 12:13:51 -0700 automation: push changes affecting .hgtags stable
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 03 Aug 2019 12:13:51 -0700] rev 42658
automation: push changes affecting .hgtags When I went to build the 5.1 tag using the in-repo automation, the automatic version calculation failed to deduce the clean 5.1 version string because we had only pushed the changeset corresponding to the 5.1 tag and not the changeset containing the 5.1 tag. So from the perspective of the remote repo, the 5.1 tag didn't exist yet and automatic version deduction failed. This commit changes the `hg push` to also push all changesets affecting the .hgtags file, ensuring the remote has up-to-date tags information. I tested this by creating a local draft changeset with a dummy tag value on a different DAG head and instructed the automation to build a revision that didn't have this change to .hgtags. The tag was successfully pushed and the built package had a version number incorporating that tag. Sending this to stable so the 5.1.1 automation hopefully "just works."
Fri, 21 Jun 2019 03:50:40 +0200 bookmarks: actual fix for race condition deleting bookmark stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 21 Jun 2019 03:50:40 +0200] rev 42657
bookmarks: actual fix for race condition deleting bookmark This is a simple but efficient fix to prevent the issue tested in `test-bookmarks-corner-case.t`. It might be worth pursuing a more generic approach where filecache learn to depend on each other, but that would not be suitable for stable. The issue is complicated enough that I documented the race and its current solution as inline comment. See this comment for details on the fix.
Thu, 01 Aug 2019 16:22:47 +0200 strip: access bookmark before getting a reference to changelog stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Aug 2019 16:22:47 +0200] rev 42656
strip: access bookmark before getting a reference to changelog Bookmark access might invalidate the current changelog (to make sure both are in a reasonable synchronisation state). So we should grab the reference to changelog after we access bookmark. Otherwise we risk using a dead object for the whole strip process. (note: this dead object business probably requires a new layers of checking)
Thu, 01 Aug 2019 15:59:52 +0200 test: use a more verbose output in the test stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 01 Aug 2019 15:59:52 +0200] rev 42655
test: use a more verbose output in the test While debugging some test failure, I released the test never checks if the relevant changesets were preserved. So I am updating the test from `hg parents` usage to `hg log -G` with a special template. This increase the area covered by the test and clarify the test failures.
Thu, 01 Aug 2019 12:14:52 -0400 Added signature for changeset e91930d712e8 stable
Augie Fackler <raf@durin42.com> [Thu, 01 Aug 2019 12:14:52 -0400] rev 42654
Added signature for changeset e91930d712e8
Thu, 01 Aug 2019 12:14:50 -0400 Added tag 5.1 for changeset e91930d712e8 stable
Augie Fackler <raf@durin42.com> [Thu, 01 Aug 2019 12:14:50 -0400] rev 42653
Added tag 5.1 for changeset e91930d712e8
Sun, 28 Jul 2019 18:32:31 -0700 automation: execute powershell when connecting stable 5.1
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 28 Jul 2019 18:32:31 -0700] rev 42652
automation: execute powershell when connecting For some reason, the ability to execute PS scripts appears to come online after the ability to execute regular command scripts. This is creating race conditions when connecting to instances resulting in our wait_for_winrm() returning before PS is available leading to an exception being thrown in other code. Let's change the client connection code to execute a minimal PS script so we can try to trap the exception in wait_for_winrm().
Sun, 28 Jul 2019 18:16:08 -0700 automation: allow exit code of 1 for `hg push` stable
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 28 Jul 2019 18:16:08 -0700] rev 42651
automation: allow exit code of 1 for `hg push` `hg push` exits 1 for no-ops. No-op pushes should be fine in the context of automation.
Thu, 25 Jul 2019 21:28:29 +0900 curses: do not setlocale() at import time (issue5261) stable
Yuya Nishihara <yuya@tcha.org> [Thu, 25 Jul 2019 21:28:29 +0900] rev 42650
curses: do not setlocale() at import time (issue5261) setlocale() can break date formatting/parsing functions because they are locale dependent. We should avoid doing setlocale() as possible. This patch moves setlocale() just before curses.wrapper(), which function is documented to "initialize curses." I don't know the details about the curses initialization, but I *think* this would work as well. Maybe we can extract a curses setup function later. https://www.mercurial-scm.org/pipermail/mercurial-devel/2019-February/128788.html
Mon, 22 Jul 2019 19:10:59 -0700 contrib: install Python 3.8b2 instead of 3.8a2 stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 19:10:59 -0700] rev 42649
contrib: install Python 3.8b2 instead of 3.8a2 Let's install the most recent Python 3.8 distribution. Differential Revision: https://phab.mercurial-scm.org/D6674
Mon, 22 Jul 2019 19:06:20 -0700 automation: make Windows base image name configurable stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 19:06:20 -0700] rev 42648
automation: make Windows base image name configurable Since automation broke in the middle of the 5.0 release cycle, there's a good chance it will break again in the future. While a robust solution might be to search for all available images and choose the newest one, it does seem useful to be able to explicitly choose the name of the image to find and use so users can opt in to using a different image. This commit implements that functionality. Differential Revision: https://phab.mercurial-scm.org/D6673
Mon, 22 Jul 2019 18:55:52 -0700 automation: extract strings to constants stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 18:55:52 -0700] rev 42647
automation: extract strings to constants Differential Revision: https://phab.mercurial-scm.org/D6672
Mon, 22 Jul 2019 18:52:58 -0700 automation: use newer Windows base image stable
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 22 Jul 2019 18:52:58 -0700] rev 42646
automation: use newer Windows base image It looks like the old base image disappeared. Let's use a newer image that exists today. Differential Revision: https://phab.mercurial-scm.org/D6671
Mon, 22 Jul 2019 17:44:19 -0700 copies: fix crash on in changeset-centric tracing from commit to itself stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jul 2019 17:44:19 -0700] rev 42645
copies: fix crash on in changeset-centric tracing from commit to itself When we trace copies from a changeset to itself, the "work" queue ends up empty and we hit the "assert False" after it. It was only the last of the three added tests that failed before this patch. That is because the other two cases have fast paths, so _committedforwardcopies() is never reached. Differential Revision: https://phab.mercurial-scm.org/D6675
Tue, 23 Jul 2019 12:03:24 +0530 unshelve: add help text on --interactive in verbose mode stable
Navaneeth Suresh <navaneeths1998@gmail.com> [Tue, 23 Jul 2019 12:03:24 +0530] rev 42644
unshelve: add help text on --interactive in verbose mode This is a follow-up patch to rHG9eace8d6d537. This modifies the help text of unshelve in verbose mode to mention the details about `--interactive` flag. Differential Revision: https://phab.mercurial-scm.org/D6676
Mon, 22 Jul 2019 06:33:11 -0400 amend: stop committing unrequested file reverts (issue6157) stable
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 22 Jul 2019 06:33:11 -0400] rev 42643
amend: stop committing unrequested file reverts (issue6157) Differential Revision: https://phab.mercurial-scm.org/D6667
Mon, 22 Jul 2019 06:33:00 -0400 amend: add a test for a simplified version of issue6157 stable
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 22 Jul 2019 06:33:00 -0400] rev 42642
amend: add a test for a simplified version of issue6157 Differential Revision: https://phab.mercurial-scm.org/D6666
Sun, 21 Jul 2019 18:04:05 -0700 py: error out if a "skip" character was given with non-dict to util.dirs() stable
Martin von Zweigbergk <martinvonz@google.com> [Sun, 21 Jul 2019 18:04:05 -0700] rev 42641
py: error out if a "skip" character was given with non-dict to util.dirs() util.dirs() keeps track of the directories in its input collection. If a "skip" character is given to it, it will assume the input is a dirstate map and it will skip entries that are in the given "skip" state. I think this is used only for skipping removed entries ("r") in the dirtate. The C implementation of util.dirs() errors out if it was given a skip character and a non-dict was passed. The pure implementation simply ignored the request skip state. Let's make it easier to discover bugs here by erroring out in the pure implementation too. Let's also switch to checking for the dict-ness, to make the C implementation (since that's clearly been sufficient for many years). This last change makes test-issue660.t pass on py3 in pure mode, since the old check was for existence of iteritems(), which doesn't exist on py3. Differential Revision: https://phab.mercurial-scm.org/D6669
Mon, 22 Jul 2019 09:55:05 -0700 py3: fix incorrect fix of test-setdiscovery.t in eb27d9eee2cc stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jul 2019 09:55:05 -0700] rev 42640
py3: fix incorrect fix of test-setdiscovery.t in eb27d9eee2cc Both places should have been changed from 185 to 187. Differential Revision: https://phab.mercurial-scm.org/D6668
Mon, 22 Jul 2019 14:08:56 -0400 Added signature for changeset e386b5f4f836 stable
Augie Fackler <raf@durin42.com> [Mon, 22 Jul 2019 14:08:56 -0400] rev 42639
Added signature for changeset e386b5f4f836
Mon, 22 Jul 2019 14:08:54 -0400 Added tag 5.1rc0 for changeset e386b5f4f836 stable
Augie Fackler <raf@durin42.com> [Mon, 22 Jul 2019 14:08:54 -0400] rev 42638
Added tag 5.1rc0 for changeset e386b5f4f836
Mon, 22 Jul 2019 14:00:33 -0400 merge default into stable for 5.1 release stable 5.1rc0
Augie Fackler <augie@google.com> [Mon, 22 Jul 2019 14:00:33 -0400] rev 42637
merge default into stable for 5.1 release
Sun, 21 Jul 2019 14:42:01 +0900 rust-filepatterns: unescape comment character property
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 14:42:01 +0900] rev 42636
rust-filepatterns: unescape comment character property There were multiple issues in the original implementation: a. the local variable "line" dropped soon after replace_slice() applied b. replace_slice() was noop since br"\#".len() != b"#" This patch uses bytes::Regex::replace_all() since it seems the simplest way to replace bytes of arbitrary length, and I don't think we have to avoid using Regexp here.
Sun, 21 Jul 2019 13:00:54 +0900 rust-filepatterns: use literal b'#' instead of cast
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:00:54 +0900] rev 42635
rust-filepatterns: use literal b'#' instead of cast
Sun, 21 Jul 2019 12:46:57 +0900 rust-filepatterns: fix type of warnings tuple to (bytes, bytes)
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 12:46:57 +0900] rev 42634
rust-filepatterns: fix type of warnings tuple to (bytes, bytes) Otherwise warn() in match.py would fail if the warning contains non-ASCII character. We might want to add a thin ByteString wrapper around Vec<u8> to implement ToPyObject<ObjectType = PyBytes>, but I'm not sure.
Sun, 21 Jul 2019 13:48:29 +0900 hgignore: add escape syntax test for glob patterns
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:48:29 +0900] rev 42633
hgignore: add escape syntax test for glob patterns The last example, [\#], is what the rust implementation fails to parse. The other escapes can be removed by regexp engine or _globre().
Sun, 21 Jul 2019 13:37:24 +0900 hgignore: add a few more weird patterns to test case
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:37:24 +0900] rev 42632
hgignore: add a few more weird patterns to test case
Sun, 21 Jul 2019 13:30:47 +0900 hgignore: update \-escape test to reflect actual behavior
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Jul 2019 13:30:47 +0900] rev 42631
hgignore: update \-escape test to reflect actual behavior "\\<char>" is not an escape character but "\\" + <char>.
Sat, 20 Jul 2019 11:04:49 -0700 py3: add a b'' prefix in tests/test-convert-identity.t
Martin von Zweigbergk <martinvonz@google.com> [Sat, 20 Jul 2019 11:04:49 -0700] rev 42630
py3: add a b'' prefix in tests/test-convert-identity.t Differential Revision: https://phab.mercurial-scm.org/D6662
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip