Tue, 12 Mar 2019 14:58:35 -0700 patch: include newline at EOF in help text for interactive patch
Martin von Zweigbergk <martinvonz@google.com> [Tue, 12 Mar 2019 14:58:35 -0700] rev 41986
patch: include newline at EOF in help text for interactive patch The lack of a newline means that some "editors" that are useful in tests, such as `echo "+new line" >> "$1"` don't work. It's obviously easy to work around it, but newline at EOF seems like a good practice anyway. Differential Revision: https://phab.mercurial-scm.org/D6124
Tue, 19 Mar 2019 16:36:59 +0300 merge with stable
Pulkit Goyal <pulkit@yandex-team.ru> [Tue, 19 Mar 2019 16:36:59 +0300] rev 41985
merge with stable
Tue, 19 Mar 2019 09:23:35 -0400 Added signature for changeset 4ea21df312ec stable
Augie Fackler <raf@durin42.com> [Tue, 19 Mar 2019 09:23:35 -0400] rev 41984
Added signature for changeset 4ea21df312ec
Tue, 19 Mar 2019 09:23:33 -0400 Added tag 4.9.1 for changeset 4ea21df312ec stable
Augie Fackler <raf@durin42.com> [Tue, 19 Mar 2019 09:23:33 -0400] rev 41983
Added tag 4.9.1 for changeset 4ea21df312ec
Sun, 03 Mar 2019 20:16:22 +0530 patch: include flag-only file changes in "special" when filtering (issue5864)
Sushil khanchi <sushilkhanchi97@gmail.com> [Sun, 03 Mar 2019 20:16:22 +0530] rev 41982
patch: include flag-only file changes in "special" when filtering (issue5864) This patch fix the issue5864 (or maybe issue5865 too) which occurs during split (or I should say at the time of filtering the hunks in interactive mode) where user hits a not ending loop of "no changes to record". And it's not only the case for split it will happen in every interactive case for e.g. `hg commit -i` or `hg uncommit -i` After looking into code I found that when filtering we have some notation called "special" for the file headers which doesn't contain any hunk and just contain the header (for e.g. newly added empty file or deleted file) where the user cannot change the content of operation. And I think we can put this "flag-only" file change in that same bucket of "special". But I doubt a bit about the case when a file have flag change and atleast one hunk then user won't be able to separate the flag change from hunks. Changed test file reflect the fixed behaviour. Differential Revision: https://phab.mercurial-scm.org/D6058
Mon, 18 Mar 2019 16:56:24 +0300 store: error out if fncache does not ends with a newline
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 16:56:24 +0300] rev 41981
store: error out if fncache does not ends with a newline If fncache does not ends with a newline, chunk will not be fully consumed. It should be a bug somewhere or the fncache is corrupted if that happens. Let's error out in such cases. Differential Revision: https://phab.mercurial-scm.org/D6148
Mon, 18 Mar 2019 14:57:43 +0300 tracked: add documentation about `--import-rules` flag
Pulkit Goyal <pulkit@yandex-team.ru> [Mon, 18 Mar 2019 14:57:43 +0300] rev 41980
tracked: add documentation about `--import-rules` flag The documentation is inspired from the `--import-rules` flag of hg debugsparse command. Differential Revision: https://phab.mercurial-scm.org/D6150
Thu, 14 Mar 2019 19:13:45 +0000 discovery: fix embarrassing typo in slice definition
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 19:13:45 +0000] rev 41979
discovery: fix embarrassing typo in slice definition The code introduced in e514799e4e07 ended up having a silly bug. The indexing selected a single item slice picking only p1. The discovery result was still correct, but the sampling was hampered, sometime leading to much more round trips being performed. Fixing this issue restore the previous sampling behavior. This fix has a negative performance impact on the pathological case the previous test has been built. # parent of this changesets ! wall 5.313884 comb 5.310000 user 5.260000 sys 0.050000 (best of 5) ! wall 6.711860 comb 6.710000 user 6.670000 sys 0.040000 (max of 5) ! wall 5.844016 comb 5.842000 user 5.784000 sys 0.058000 (avg of 5) ! wall 5.778635 comb 5.780000 user 5.740000 sys 0.040000 (median of 5) # With this changesets. ! wall 6.350879 comb 6.350000 user 6.300000 sys 0.050000 (best of 5) ! wall 6.653647 comb 6.660000 user 6.480000 sys 0.180000 (max of 5) ! wall 6.492762 comb 6.494000 user 6.414000 sys 0.080000 (avg of 5) ! wall 6.547577 comb 6.550000 user 6.490000 sys 0.060000 (median of 5) Changeset e514799e4e07 raised the question of using the "_uncheckedparentrevs" instead of the current code. So I ran comparative timing: # old code: 55919b96c02a (e514799e4e07 parent) ! wall 64.078708 comb 64.080000 user 63.160000 sys 0.920000 (best of 5) ! wall 68.296300 comb 68.290000 user 67.410000 sys 0.880000 (max of 5) ! wall 65.899075 comb 65.894000 user 65.082000 sys 0.812000 (avg of 5) ! wall 66.140286 comb 66.130000 user 65.330000 sys 0.800000 (median of 5) # buggy code: e514799e4e07 ! wall 46.605362 comb 46.610000 user 45.880000 sys 0.730000 (best of 5) ! wall 48.619659 comb 48.620000 user 47.890000 sys 0.730000 (max of 5) ! wall 47.350247 comb 47.350000 user 46.672000 sys 0.678000 (avg of 5) ! wall 46.983224 comb 46.980000 user 46.350000 sys 0.630000 (median of 5) # fixed code: e514799e4e07 with this fix ! wall 55.858460 comb 55.850000 user 55.090000 sys 0.760000 (best of 5) ! wall 59.048805 comb 59.060000 user 58.110000 sys 0.950000 (max of 5) ! wall 57.192639 comb 57.192000 user 56.350000 sys 0.842000 (avg of 5) ! wall 57.056373 comb 57.060000 user 56.160000 sys 0.900000 (median of 5) # version using uncheckedparents ! wall 56.471916 comb 56.470000 user 55.630000 sys 0.840000 (best of 5) ! wall 58.228793 comb 58.230000 user 57.600000 sys 0.630000 (max of 5) ! wall 57.377583 comb 57.378000 user 56.674000 sys 0.704000 (avg of 5) ! wall 57.008843 comb 57.010000 user 56.330000 sys 0.680000 (median of 5) So it looks like the overhead from `_uncheckedparentrevs` is not that impactful. I'll investigate this shortly. I'm almost done updating our benchmark suite with more meaningful discovery cases.
Thu, 22 Nov 2018 15:14:24 +0300 store: don't read the whole fncache in memory
Pulkit Goyal <pulkit@yandex-team.ru> [Thu, 22 Nov 2018 15:14:24 +0300] rev 41978
store: don't read the whole fncache in memory In large repositories with lot of files, the fncache grows more than 100 MB and reading that whole thing into memory slows things down. Let's not read the whole thing into memory. This patch changes fncache loading code to read 1 MB at once. Loading 1 MB at once saves ~1 sec on perffncacheload for our internal repository. I tried various values such as 0.5 MB, 5 MB, 10 MB but best results were produced using 1 MB as the chunksize. On a narrow clone with fncache around 40 MB, this patch saves ~0.04 seconds on average on perffncacheload. To test the code, I have coded an extension in test-fncache.t which set chunksize to 1 byte, and the test passes with that. Differential Revision: https://phab.mercurial-scm.org/D5296
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 41977
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.
Fri, 08 Mar 2019 10:20:33 -0800 wix: restore COPYING.rtf
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 08 Mar 2019 10:20:33 -0800] rev 41976
wix: restore COPYING.rtf 8427fea04017 accidentally blew away the content of this file. As part of restoring the content, I updated the copyright year to 2019. Differential Revision: https://phab.mercurial-scm.org/D6098
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 41975
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 41974
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.
Wed, 27 Feb 2019 16:29:48 +0300 store: move logic to check for invalid entry in fncache to own function
Pulkit Goyal <pulkit@yandex-team.ru> [Wed, 27 Feb 2019 16:29:48 +0300] rev 41973
store: move logic to check for invalid entry in fncache to own function This helps separate the original reading logic from the one which finds for an invalid entry. Differential Revision: https://phab.mercurial-scm.org/D6030
Sat, 09 Mar 2019 02:52:49 +0000 py3: add test-phabricator.py to python3-whitelist
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 02:52:49 +0000] rev 41972
py3: add test-phabricator.py to python3-whitelist Differential Revision: https://phab.mercurial-scm.org/D6114
Sat, 09 Mar 2019 02:18:49 +0000 py3: convert to/from bytes/unicode for json.(dump|load)s in debugcallconduit
Ian Moody <moz-ian@perix.co.uk> [Sat, 09 Mar 2019 02:18:49 +0000] rev 41971
py3: convert to/from bytes/unicode for json.(dump|load)s in debugcallconduit Differential Revision: https://phab.mercurial-scm.org/D6113
Fri, 08 Mar 2019 18:30:12 +0000 py3: use pycompat.byteskwargs on opts in phabricator.py
Ian Moody <moz-ian@perix.co.uk> [Fri, 08 Mar 2019 18:30:12 +0000] rev 41970
py3: use pycompat.byteskwargs on opts in phabricator.py Differential Revision: https://phab.mercurial-scm.org/D6107
Fri, 21 Dec 2018 17:12:39 +0100 watchman: ignore some of watchman errors
Boris Feld <boris.feld@octobus.net> [Fri, 21 Dec 2018 17:12:39 +0100] rev 41969
watchman: ignore some of watchman errors Don't display 'illegal_fstypes' errors. In environments with network filesystems, the error messages are quickly pilling up and polluting outputs. Differential Revision: https://phab.mercurial-scm.org/D5955
Fri, 21 Dec 2018 17:10:54 +0100 watchman: add the possibility to set the exact watchman binary location
Boris Feld <boris.feld@octobus.net> [Fri, 21 Dec 2018 17:10:54 +0100] rev 41968
watchman: add the possibility to set the exact watchman binary location This is necessary to make rolling releases of new watchman versions across users. Differential Revision: https://phab.mercurial-scm.org/D5954
Fri, 15 Mar 2019 22:18:35 -0700 context: use wdirhex constant instead of calculating it
Martin von Zweigbergk <martinvonz@google.com> [Fri, 15 Mar 2019 22:18:35 -0700] rev 41967
context: use wdirhex constant instead of calculating it Differential Revision: https://phab.mercurial-scm.org/D6143
Wed, 13 Mar 2019 11:30:04 -0700 split: use the new movedirstate() we now have in scmutil
Martin von Zweigbergk <martinvonz@google.com> [Wed, 13 Mar 2019 11:30:04 -0700] rev 41966
split: use the new movedirstate() we now have in scmutil This avoids unnecessarily touching the working copy when splitting the parent of the working copy. That also makes the test-removeemptydirs.t case invalid, so we can just delete it. Differential Revision: https://phab.mercurial-scm.org/D6127
Thu, 14 Mar 2019 00:40:11 +0000 manifestcache: use `wcache` directory for manifest cache
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 00:40:11 +0000] rev 41965
manifestcache: use `wcache` directory for manifest cache The manifest full text cache is tightly related to the working copy. We should use the `wcache` directory for it, instead of the `cache`. Otherwise, multiple shares would keep overwriting each other cache entry and we loose its benefit. This is also more consistent with the fact this cache file is protected by `wlock`.
Fri, 15 Mar 2019 15:07:43 +0000 manifestcache: protect write with `wlock` instead of `lock`
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 15:07:43 +0000] rev 41964
manifestcache: protect write with `wlock` instead of `lock` The `wlock` is taken by both `update` and `commit` type operation. This would help persisting the cache more aggressively. An explicit test is introduced. However, we can already see the effect of this change on earlier test output.
Thu, 14 Mar 2019 09:12:55 +0000 manifestcache: clear the cache before testing the debug command
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 09:12:55 +0000] rev 41963
manifestcache: clear the cache before testing the debug command Right now the cache is empty before this section of the test. However, we are about to improve the persistence of the cache (putting it under `wllock`, intead of `lock`). So we install the cleanup before.
Fri, 15 Mar 2019 12:17:30 +0000 manifestcache: abstract the filename in a class attribute
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 12:17:30 +0000] rev 41962
manifestcache: abstract the filename in a class attribute This make the code clearer and simpler to update.
Fri, 15 Mar 2019 09:07:23 +0000 manifestcache: skip setup earlier if we don't have the lock
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 09:07:23 +0000] rev 41961
manifestcache: skip setup earlier if we don't have the lock There a no point preparing a closure if we are not going to use it.
Thu, 14 Mar 2019 11:46:18 +0000 manifestcache: test the cache is warm after a commit
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 14 Mar 2019 11:46:18 +0000] rev 41960
manifestcache: test the cache is warm after a commit
Fri, 15 Mar 2019 13:52:36 +0000 manifestcache: stop altering the lru cache order while displaying it
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 13:52:36 +0000] rev 41959
manifestcache: stop altering the lru cache order while displaying it Accessing value with `.get` alter the iteration order and make the output of the debug command misbehave, showing multiple entry twice. We need more than 2 entry to see the bug, so there are not test change. Later test will introduce a third entry and would fail without this fix.
Fri, 15 Mar 2019 13:52:56 +0000 manifestcache: support multiple cache addition in one debug command run
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 15 Mar 2019 13:52:56 +0000] rev 41958
manifestcache: support multiple cache addition in one debug command run This is more practical.
Thu, 14 Mar 2019 18:11:22 -0700 wix: autogenerate wxs file for library files
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 14 Mar 2019 18:11:22 -0700] rev 41957
wix: autogenerate wxs file for library files Currently, dist.wxs contains an enumeration of .pyd and .dll files staged to dist/lib by py2exe. Having a manual list of files is error prone, as things can easily get out of sync (as the previous commit demonstrates). This is especially an issue for TortoiseHG, which ships a number of custom modules, which may pull in additional dependencies. Let's prevent this problem from manifesting by dynamically generating a .wxs file containing the .pyd and .dll files staged by py2exe. Differential Revision: https://phab.mercurial-scm.org/D6139
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip