Sat, 16 Mar 2019 14:40:21 -0400 record: prevent commits that don't pick up dirty subrepo changes (issue6102) stable 4.9.1
Matt Harbison <matt_harbison@yahoo.com> [Sat, 16 Mar 2019 14:40:21 -0400] rev 41330
record: prevent commits that don't pick up dirty subrepo changes (issue6102) This path covers interactive mode for commit, amend, and shelve, as well as the deprecated record extension. Since shelf creation uses commit without -S in the non-interactive case, aborting here should be OK. (I didn't check what happens to non interactive shelve creation if `ui.commitsubrepos=True` is set.) subrepoutil.precommit() will abort on a dirty subrepo if the config option isn't set, but the hint recommends using --subrepos to commit. Since only the commit command currently supports that option, the error has to be raised here to omit the hint. Doing the check before asking about all of the hunks in the MQ test seems like an improvement on its own. There's probably an additional check on this path that can be removed.
Sun, 17 Mar 2019 12:43:45 +0900 test-https: add some more known failure messages of client certs (issue6030) stable
Yuya Nishihara <yuya@tcha.org> [Sun, 17 Mar 2019 12:43:45 +0900] rev 41329
test-https: add some more known failure messages of client certs (issue6030) I don't think the exact error message is important here. On Debian sid, ECONNRESET is raised, and "[SSL] tlsv13 alert certificate required" on NetBSD.
Sun, 17 Mar 2019 12:37:57 +0900 test-https: turn off system OpenSSL configuration stable
Yuya Nishihara <yuya@tcha.org> [Sun, 17 Mar 2019 12:37:57 +0900] rev 41328
test-https: turn off system OpenSSL configuration This mostly fixes the test failure on Debian sid where TLS 1.0 and 1.1 are disabled by default. https://sources.debian.org/patches/openssl/1.1.1a-1/Set-systemwide-default-settings-for-libssl-users.patch/ $OPENSSL_CONF could be set by run-tests.py, but the other tests should work without a "legacy" TLS, so I decided to not.
Sat, 23 Feb 2019 21:13:27 +0100 rebase: add missing dashes in help text stable
Manuel Jacob <me@manueljacob.de> [Sat, 23 Feb 2019 21:13:27 +0100] rev 41327
rebase: add missing dashes in help text
Sun, 24 Feb 2019 19:56:46 +0100 test: stabilize bundle generation for test-sparse-revlog.t stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 24 Feb 2019 19:56:46 +0100] rev 41326
test: stabilize bundle generation for test-sparse-revlog.t To reduce the instability in the bundle binary content, we force it to contains delta against p1 in all cases. In the previous changeset, we already stabilized the processing of the bundle. So we don't see any output change in the test itself.
Sun, 24 Feb 2019 19:56:51 +0100 test: don't trust delta bases from the bundle in test-sparse-revlog.t stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 24 Feb 2019 19:56:51 +0100] rev 41325
test: don't trust delta bases from the bundle in test-sparse-revlog.t The point of the test is to check the strategy sparse-revlog uses to pick delta base. If we trust the bases used in the bundle, we no longer fully test this logic. In order to force this computation we have to use the side effect of a legacy format configuration `format.generaldelta`. The lack of a more official way to do so will be fixed in a later changeset.
Sun, 24 Feb 2019 19:56:57 +0100 test: update test-sparse-revlog.t output stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 24 Feb 2019 19:56:57 +0100] rev 41324
test: update test-sparse-revlog.t output This test is skipped unless a large artefact is pre-build. It seems like nobody ran it in a while. Changeset 3764330f76a6 changed the expected output but nobody noticed. This changeset focus on the first and simpler step: putting the expected output back to what one would get by running this test. However this test changes highlight a couple of deeper issues: 1) Even if the revision content did not changed, a change in the delta contained in the bundle affected the delta stored in the final revlog, changing the test result. Since we are testing the delta computation strategy with sparse, we should not blindly reuse the delta-base from the bundled delta. 2) A change in the format of the repository used to generate the bundle changed the delta stored in the bundle. We should get a more stable output to avoid future instabilities of this test. 3) The test is it not run by CI or developer. We'll try to address all this issues in the coming changesets.
Wed, 20 Feb 2019 20:57:58 -0500 tests: add a missing abort exit code on Windows in test-audit-subrepo.t stable
Matt Harbison <matt_harbison@yahoo.com> [Wed, 20 Feb 2019 20:57:58 -0500] rev 41323
tests: add a missing abort exit code on Windows in test-audit-subrepo.t
Thu, 07 Feb 2019 20:50:41 +0900 subrepo: add test for Windows relative-ish path with drive letter stable
Yuya Nishihara <yuya@tcha.org> [Thu, 07 Feb 2019 20:50:41 +0900] rev 41322
subrepo: add test for Windows relative-ish path with drive letter Matt Harbison pointed out that Windows had some weird path syntax. Fortunately it's rejected appropriately by pathauditor, so we're safe. Let's test the behavior as we have a special handling for Windows drive letters. This patch includes a basic example. Maybe we'll need to extend the test case further, but writing such tests on Linux isn't easy.
Thu, 07 Feb 2019 11:08:54 +0100 tests: fix regression tests failing on CentOS 7 stable
Mathias De Mare <mathias.de_mare@nokia.com> [Thu, 07 Feb 2019 11:08:54 +0100] rev 41321
tests: fix regression tests failing on CentOS 7 Differential Revision: https://phab.mercurial-scm.org/D5877
Thu, 07 Feb 2019 09:12:01 +0100 packaging: modify rc detection to work with X.Yrc instead of X.Y-rc stable
Mathias De Mare <mathias.de_mare@nokia.com> [Thu, 07 Feb 2019 09:12:01 +0100] rev 41320
packaging: modify rc detection to work with X.Yrc instead of X.Y-rc rc detection on CentOS failed without this change, resulting in upgrades from 4.9rc to 4.9 not working (4.9rc was considered more recent than 4.9). Differential Revision: https://phab.mercurial-scm.org/D5876
Tue, 05 Feb 2019 20:50:54 -0500 subrepo: avoid false unsafe path detection on Windows stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 05 Feb 2019 20:50:54 -0500] rev 41319
subrepo: avoid false unsafe path detection on Windows Subrepo paths are not normalized for the OS, so what was happening in the subsequent root path check was: root -> $TESTTMP\issue1852a\sub/repo util.expandpath(...) -> $TESTTMP\issue1852a\sub/repo os.path.realpath(...) -> $TESTTMP\issue1852a\sub\repo
Fri, 01 Feb 2019 13:44:09 -0500 Added signature for changeset 83377b4b4ae0 stable
Augie Fackler <raf@durin42.com> [Fri, 01 Feb 2019 13:44:09 -0500] rev 41318
Added signature for changeset 83377b4b4ae0
Fri, 01 Feb 2019 13:44:07 -0500 Added tag 4.9 for changeset 83377b4b4ae0 stable
Augie Fackler <raf@durin42.com> [Fri, 01 Feb 2019 13:44:07 -0500] rev 41317
Added tag 4.9 for changeset 83377b4b4ae0
Tue, 08 Jan 2019 22:19:36 +0900 subrepo: reject potentially unsafe subrepo paths (BC) (SEC) stable 4.9
Yuya Nishihara <yuya@tcha.org> [Tue, 08 Jan 2019 22:19:36 +0900] rev 41316
subrepo: reject potentially unsafe subrepo paths (BC) (SEC) In addition to the previous patch, this prohibits '~', '$nonexistent', etc. for any subrepo types. I think this is safer, and real-world subrepos wouldn't use such (local) paths.
Tue, 08 Jan 2019 22:07:45 +0900 subrepo: prohibit variable expansion on creation of hg subrepo (SEC) stable
Yuya Nishihara <yuya@tcha.org> [Tue, 08 Jan 2019 22:07:45 +0900] rev 41315
subrepo: prohibit variable expansion on creation of hg subrepo (SEC) It's probably wrong to expand path at localrepo.*repository() layer, but fixing the layering issue would require careful inspection of call paths. So, this patch adds add a validation to the subrepo constructor. os.path.realpath(util.expandpath(root)) is what vfsmod.vfs() would do.
Tue, 08 Jan 2019 21:51:54 +0900 subrepo: extend path auditing test to include more weird patterns (SEC) stable
Yuya Nishihara <yuya@tcha.org> [Tue, 08 Jan 2019 21:51:54 +0900] rev 41314
subrepo: extend path auditing test to include more weird patterns (SEC) While reviewing patches for the issue 5739, "$foo in repository path expanded", I realized that subrepo paths can also be cheated. This patch includes various subrepo paths which are potentially unsafe. Since an expanded subrepo path isn't audited, this bug allows symlink check bypass. As a result, a malicious subrepository could be checked out to a sub tree of e.g. $HOME directory. The good news is that the destination directory must be empty or nonexistent, so the existing ~/.bashrc wouldn't be overwritten. See the last part of the tests for details.
Thu, 31 Jan 2019 13:32:21 +0800 copyright: update to 2019 stable
Anton Shestakov <av6@dwimlabs.net> [Thu, 31 Jan 2019 13:32:21 +0800] rev 41313
copyright: update to 2019 Differential Revision: https://phab.mercurial-scm.org/D5779
Thu, 24 Jan 2019 18:22:47 -0500 revlog: make sure we never use sparserevlog without general delta (issue6056) stable
Boris Feld <boris.feld@octobus.net> [Thu, 24 Jan 2019 18:22:47 -0500] rev 41312
revlog: make sure we never use sparserevlog without general delta (issue6056) We are getting user report where the delta code tries to use `sparse-revlog` logic on repository where `generaldelta` is disabled. This can't work so we ensure the two booleans have a consistent value. Creating this kind of repository is not expected to be possible the current bug report point at a clonebundle related bug that is still to be properly isolated (Yuya Nishihara seems to a have done it). Corrupting a repository to reproduce the issue is possible. A test using this method is included in this fix.
Wed, 30 Jan 2019 18:15:38 +0100 sparserevlog: document the config option stable
Boris Feld <boris.feld@octobus.net> [Wed, 30 Jan 2019 18:15:38 +0100] rev 41311
sparserevlog: document the config option This was overlooked when this graduated from experimental.
Wed, 23 Jan 2019 07:49:36 -0500 rust-cpython: raising error.WdirUnsupported stable
Georges Racinet <georges.racinet@octobus.net> [Wed, 23 Jan 2019 07:49:36 -0500] rev 41310
rust-cpython: raising error.WdirUnsupported The Graph implementation of hg-cpython returns the appropriate error upon encounter with the working directory special revision number, and this gives us in particular a code path to test from test-rust-ancestors.py In the current implementation, the exception is actually raised from the iterator instantiation; we are nonetheless consuming the iterator in the test with `list()` in order not to depend on implementation details.
Wed, 23 Jan 2019 07:47:04 -0500 rust: error for WdirUnsupported with cpython conversion as exception stable
Georges Racinet <georges.racinet@octobus.net> [Wed, 23 Jan 2019 07:47:04 -0500] rev 41309
rust: error for WdirUnsupported with cpython conversion as exception This introduces WorkingDirectoryUnsupported as an enum variant of GraphError in the core and converts it to the expected `mercurial.error.WdirUnsupported`.
Wed, 23 Jan 2019 07:39:27 -0500 rust: working directory revision number constant stable
Georges Racinet <georges.racinet@octobus.net> [Wed, 23 Jan 2019 07:39:27 -0500] rev 41308
rust: working directory revision number constant This introduces the constant, but does not use it anywhere yet.
Thu, 24 Jan 2019 21:38:02 +0900 ui: remove unreachable branches and function calls from write() (issue6059) stable
Yuya Nishihara <yuya@tcha.org> [Thu, 24 Jan 2019 21:38:02 +0900] rev 41307
ui: remove unreachable branches and function calls from write() (issue6059) This is at least faster than ui.write() of 4.8.2. $ HGRCPATH=/dev/null hg files -R mozilla-central --time >/dev/null 4.8.2: time: real 2.340 secs (user 2.310+0.000 sys 0.020+0.000) 4.9rc0: time: real 2.580 secs (user 2.550+0.000 sys 0.020+0.000) this: time: real 2.230 secs (user 2.210+0.000 sys 0.020+0.000) Maybe the formatter should own a resolved write() function because it will just call dest.write(msg) most of the time, but that would be too much for stable.
Thu, 24 Jan 2019 21:35:55 +0900 ui: inline _writenobuf() into write() due to performance issue stable
Yuya Nishihara <yuya@tcha.org> [Thu, 24 Jan 2019 21:35:55 +0900] rev 41306
ui: inline _writenobuf() into write() due to performance issue I'll remove redundant conditions later in this series.
Thu, 24 Jan 2019 21:34:48 +0900 ui: inline _write() into write() due to performance issue stable
Yuya Nishihara <yuya@tcha.org> [Thu, 24 Jan 2019 21:34:48 +0900] rev 41305
ui: inline _write() into write() due to performance issue I'll remove redundant conditions later in this series.
Wed, 28 Nov 2018 22:36:24 +0900 ui: optimize buffered write with no label stable
Yuya Nishihara <yuya@tcha.org> [Wed, 28 Nov 2018 22:36:24 +0900] rev 41304
ui: optimize buffered write with no label This was spotted while making fastannotate faster again after ditching its own formatter. Since I'm going to inline _write() into ui.write(), I decided to include this patch in this series. Here, the cost of '(self.label(a, label) for a in args)' was significant in hot loops.
Wed, 23 Jan 2019 18:07:42 -0500 partialdiscovery: avoid `undecided` related computation sooner than necessary stable
Boris Feld <boris.feld@octobus.net> [Wed, 23 Jan 2019 18:07:42 -0500] rev 41303
partialdiscovery: avoid `undecided` related computation sooner than necessary Changeset 1d30be90c move the update of the `undecided` set within the `partialdiscovery` object in order to clarify the API. The update to the `undecided` set was unconditional in 1d30be90c and the first access to the `self.undecided` property triggered the initial computation of the set of undecided revisions. As a result, the set was computed much earlier, at a time where less information is available, immediately followed by an update of this set to remove common revisions. To fix this regression, we ignore the `undecided` related logic in `addcommons` when that `undecided` set has not been computed yet. Code that actually needs to know the `undecided` set will trigger its computation later. The change has no effects on semantic because the initial computation `undecided` set takes all knowns `common` into account. Example performance running `hg debugdiscovery` from a pypy repo missing 10 changesets: 870a89c6909d: 52.3ms (regression parent) 1d30be90c9dc: 72.0ms (regression) 5a5f504a7175: 64.8ms (this fix parent) this fix: 52.6ms
Mon, 21 Jan 2019 22:14:29 +0900 revlog: fix resolution of revlog version 0 stable
Yuya Nishihara <yuya@tcha.org> [Mon, 21 Jan 2019 22:14:29 +0900] rev 41302
revlog: fix resolution of revlog version 0 This partially backs out cecf3f8bccd3, "revlog: always process opener options." My understanding is that if there's no "revlog1" nor "revlog2" in .hg/requires, the repository should stick to the v0 format. The reasoning is briefly described in 31a5973fcf96, "revlog: get rid of defversion." Maybe we can drop support for missing opener options, but I didn't do that in this patch.
Sun, 20 Jan 2019 11:57:36 +0900 rust: add comment about lack of wdirrev handling stable
Yuya Nishihara <yuya@tcha.org> [Sun, 20 Jan 2019 11:57:36 +0900] rev 41301
rust: add comment about lack of wdirrev handling If hg is compiled with rust support, 'only(wdir())' crashed as "rustext.GraphError: ('ParentOutOfRange', 2147483647)", which should instead say "abort: working directory revision cannot be specified."
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 +10000 tip