Tue, 21 Jan 2020 11:40:15 -0500 lfs: enable workers by default
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 11:40:15 -0500] rev 44274
lfs: enable workers by default With the stall issue seemingly fixed, there's no reason not to use workers. The setting is left for now to keep the test output deterministic, and in case other issues come up. If none do, this can be converted to a developer setting for usage with the tests. Differential Revision: https://phab.mercurial-scm.org/D7963
Tue, 21 Jan 2020 11:32:33 -0500 lfs: fix the stall and corruption issue when concurrently uploading blobs
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 11:32:33 -0500] rev 44273
lfs: fix the stall and corruption issue when concurrently uploading blobs We've avoided the issue up to this point by gating worker usage with an experimental config. See 10e62d5efa73, and the thread linked there for some of the initial diagnosis, but essentially some data was being read from the blob before an error occurred and `keepalive` retried, but didn't rewind the file pointer. So the leading data was lost from the blob on the server, and the connection stalled, trying to send more data than available. In trying to recreate this, I was unable to do so uploading from Windows to CentOS 7. But it reproduced every time going from CentOS 7 to another CentOS 7 over https. I found recent fixes in the FaceBook repo to address this[1][2]. The commit message for the first is: The KeepAlive HTTP implementation is bugged in it's retry logic, it supports reading from a file pointer, but doesn't support rewinding of the seek cursor when it performs a retry. So it can happen that an upload fails for whatever reason and will then 'hang' on the retry event. The sequence of events that get triggered are: - Upload file A, goes OK. Keep-Alive caches connection. - Upload file B, fails due to (for example) failing Keep-Alive, but LFS file pointer has been consumed for the upload and fd has been closed. - Retry for file B starts, sets the Content-Length properly to the expected file size, but since file pointer has been consumed no data will be uploaded, causing the server to wait for the uploaded data until either client or server reaches a timeout, making it seem as our mercurial process hangs. This is just a stop-gap measure to prevent this behavior from blocking Mercurial (LFS has retry logic). A proper solutions need to be build on top of this stop-gap measure: for upload from file pointers, we should support fseek() on the interface. Since we expect to consume the whole file always anyways, this should be safe. This way we can seek back to the beginning on a retry. I ported those two patches, and it works. But I see that `url._sendfile()` does a rewind on `httpsendfile` objects[3], so maybe it's better to keep this all in one place and avoid a second seek. We may still want the first FaceBook patch as extra protection for this problem in general. The other two uses of `httpsendfile` are in the wire protocol to upload bundles, and to upload largefiles. Neither of these appear to use a worker, and I'm not sure why workers seem to trigger this, or if this could have happened without a worker. Since `httpsendfile` already has a `close()` method, that is dropped. That class also explicitly says there's no `__len__` attribute, so that is removed too. The override for `read()` is necessary to avoid the progressbar usage per file. [1] https://github.com/facebookexperimental/eden/commit/c350d6536d90c044c837abdd3675185644481469 [2] https://github.com/facebookexperimental/eden/commit/77f0d3fd0415e81b63e317e457af9c55c46103ee [3] https://www.mercurial-scm.org/repo/hg/file/5.2.2/mercurial/url.py#l176 Differential Revision: https://phab.mercurial-scm.org/D7962
Tue, 21 Jan 2020 10:34:15 -0500 lfs: add a method to the local blobstore to convert OIDs to file paths
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 10:34:15 -0500] rev 44272
lfs: add a method to the local blobstore to convert OIDs to file paths This is less ugly than passing an open callback to the `httpsendfile` constuctor. Differential Revision: https://phab.mercurial-scm.org/D7961
Wed, 15 Jan 2020 14:47:38 -0800 merge: introduce a revert_to() for that use-case
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 14:47:38 -0800] rev 44271
merge: introduce a revert_to() for that use-case In the same vein as the previous patch. Differential Revision: https://phab.mercurial-scm.org/D7901
Wed, 15 Jan 2020 15:30:25 -0800 merge: introduce a clean_update() for that use-case
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:30:25 -0800] rev 44270
merge: introduce a clean_update() for that use-case I find it hard to understand what value to pass for all the arguments to `merge.update()`. I would like to introduce functions that are more specific to each use-case. We already have `graft()`. This patch introduces a `clean_update()` and uses it in some places to show that it works. Differential Revision: https://phab.mercurial-scm.org/D7902
Wed, 05 Feb 2020 16:16:15 -0500 manifest: fix _very_ subtle bug with exact matchers passed to walk()
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 16:16:15 -0500] rev 44269
manifest: fix _very_ subtle bug with exact matchers passed to walk() Prior to this fix, manifestdict.walk() with an exact matcher would blindly list the files in the matcher, even if they weren't in the manifest. This was exposed by my next patch where I rewrite filesnotin() to use walk() instead of matches(). Differential Revision: https://phab.mercurial-scm.org/D8081
Tue, 14 Jan 2020 17:08:45 +0100 rust-utils: add `Escaped` trait
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 17:08:45 +0100] rev 44268
rust-utils: add `Escaped` trait This will be used as a general interface for displaying things to the user. The upcoming `IncludeMatcher` will use it to store its patterns in a user-displayable string. Differential Revision: https://phab.mercurial-scm.org/D7870
Tue, 14 Jan 2020 17:04:32 +0100 rust-dirs-multiset: add `DirsChildrenMultiset`
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 17:04:32 +0100] rev 44267
rust-dirs-multiset: add `DirsChildrenMultiset` In a future patch, this structure will be needed to store information needed by the (also upcoming) `IgnoreMatcher`. Differential Revision: https://phab.mercurial-scm.org/D7869
Tue, 14 Jan 2020 16:50:35 +0100 rust-hg-path: add useful methods to `HgPath`
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 16:50:35 +0100] rev 44266
rust-hg-path: add useful methods to `HgPath` This changeset introduces the use of the `pretty_assertions` crate for easier to read test output. Differential Revision: https://phab.mercurial-scm.org/D7867
Wed, 05 Feb 2020 17:05:37 +0100 rust-pathauditor: add Rust implementation of the `pathauditor`
Raphaël Gomès <rgomes@octobus.net> [Wed, 05 Feb 2020 17:05:37 +0100] rev 44265
rust-pathauditor: add Rust implementation of the `pathauditor` It does not offer the same flexibility as the Python implementation, but should check incoming paths just as well. Differential Revision: https://phab.mercurial-scm.org/D7866
Wed, 22 Jan 2020 03:17:06 +0530 py3: catch AttributeError too with ImportError
Pulkit Goyal <7895pulkit@gmail.com> [Wed, 22 Jan 2020 03:17:06 +0530] rev 44264
py3: catch AttributeError too with ImportError Looks like py3 raises AttributeError instead of ImportError. This is caught on windows. Differential Revision: https://phab.mercurial-scm.org/D7965
Wed, 05 Feb 2020 15:15:18 -0500 context: use manifest.walk() instead of manifest.match() to get file list
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 15:15:18 -0500] rev 44263
context: use manifest.walk() instead of manifest.match() to get file list The former doesn't create a whole extra manifest in order to produce the matching file list, which is all we actually cared about here. Sigh. Differential Revision: https://phab.mercurial-scm.org/D8080
Wed, 05 Feb 2020 15:01:22 -0500 manifest: remove `.new()` from the interface
Augie Fackler <augie@google.com> [Wed, 05 Feb 2020 15:01:22 -0500] rev 44262
manifest: remove `.new()` from the interface Nothing used it. Differential Revision: https://phab.mercurial-scm.org/D8079
Wed, 29 Jan 2020 13:39:50 -0800 chg: force-set LC_CTYPE on server start to actual value from the environment
Kyle Lippincott <spectral@google.com> [Wed, 29 Jan 2020 13:39:50 -0800] rev 44261
chg: force-set LC_CTYPE on server start to actual value from the environment Python 3.7+ will "coerce" the LC_CTYPE variable in many instances, and this can cause issues with chg being able to start up. D7550 attempted to fix this, but a combination of a misreading of the way that python3.7 does the coercion and an untested state (LC_CTYPE being set to an invalid value) meant that this was still not quite working. This change will cause differences between chg and hg: hg will have the LC_CTYPE environment variable coerced, while chg will not. This is unlikely to cause any detectable behavior differences in what Mercurial itself outputs, but it does have two known effects: - When using hg, the coerced LC_CTYPE will be passed to subprocesses, even non-python ones. Using chg will remove the coercion, and this will not happen. This is arguably more correct behavior on chg's part. - On macOS, if you set your region to Brazil but your language to English, this isn't representable in locale strings, so macOS sets LC_CTYPE=UTF-8. If this value is passed along when ssh'ing to a non-macOS machine, some functions (such as locale.setlocale()) may raise an exception due to an unsupported locale setting. This is most easily encountered when doing an interactive commit/split/etc. when using ui.interface=curses. Differential Revision: https://phab.mercurial-scm.org/D8039
Mon, 03 Feb 2020 09:00:05 +0100 perf: fix list formatting in perfindex documentation
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 03 Feb 2020 09:00:05 +0100] rev 44260
perf: fix list formatting in perfindex documentation Differential Revision: https://phab.mercurial-scm.org/D8067
Sat, 01 Feb 2020 09:14:36 +0100 test: simplify test-amend.t to avoid race condition
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 01 Feb 2020 09:14:36 +0100] rev 44259
test: simplify test-amend.t to avoid race condition Insted on relying on sleep, we could simply have the editor do the file change. This remove the reliance on "sleep" and avoid test failing on heavy load machine. To test this, I reverted the code change in 5558e3437872 and the test started failing again. Differential Revision: https://phab.mercurial-scm.org/D8065
Fri, 13 Dec 2019 11:32:36 +0100 test: document test-copy-move-merge.t
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 13 Dec 2019 11:32:36 +0100] rev 44258
test: document test-copy-move-merge.t Differential Revision: https://phab.mercurial-scm.org/D8077
Mon, 03 Feb 2020 22:16:36 -0500 manifest: remove optional default= argument on flags(path)
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 22:16:36 -0500] rev 44257
manifest: remove optional default= argument on flags(path) It had only one caller inside manifest.py, and treemanifest was actually incorrectly implemented. treemanifest is still missing the fastdelta() method from the interface (and so doesn't yet conform), but this is at least progress. Differential Revision: https://phab.mercurial-scm.org/D8069
Thu, 06 Feb 2020 15:46:55 -0800 py3: fully fix bundlepart.__repr__ to return str not bytes stable
Kyle Lippincott <spectral@google.com> [Thu, 06 Feb 2020 15:46:55 -0800] rev 44256
py3: fully fix bundlepart.__repr__ to return str not bytes My previous fix did not fully fix the issue: it would attempt to use %-formatting to combine two strs into a bytes, which won't work. Let's just switch the entire function to operating in strs. This can cause a small output difference that will likely not be noticed since no one noticed that the method wasn't working at all before: if `id` or `type` are not-None, they'll be shown as `b'val'` instead of `val`. Since this is a debugging aid and these strings shouldn't be shown to the user, slightly rough output is most likely fine and it's likely not worthwhile to add the necessary conditionals to marginally improve it. Differential Revision: https://phab.mercurial-scm.org/D8091
Sun, 17 Nov 2019 01:18:14 +0100 heptapod-ci: add a job to test the rust version of Mercurial stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 17 Nov 2019 01:18:14 +0100] rev 44255
heptapod-ci: add a job to test the rust version of Mercurial The rust version of Mercurial is not currently tested by anything else. So it get quite important that developer runs it. Differential Revision: https://phab.mercurial-scm.org/D8017
Sat, 16 Nov 2019 12:26:54 +0100 heptapod-ci: run the --pure test too stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 Nov 2019 12:26:54 +0100] rev 44254
heptapod-ci: run the --pure test too These are usually rarely run by individual developper because they are slow. However it is important that they stay happy. Differential Revision: https://phab.mercurial-scm.org/D8016
Sat, 25 Jan 2020 14:56:36 +0100 heptapod-ci: run the normal test suite stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 25 Jan 2020 14:56:36 +0100] rev 44253
heptapod-ci: run the normal test suite The usual tests should be run too. We skip the "tests-check*.t" one because their are already covered by another Ci step. Differential Revision: https://phab.mercurial-scm.org/D8015
Mon, 18 Nov 2019 09:38:40 +0100 heptapod-ci: also run the dedicated rust test for the rust code stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 18 Nov 2019 09:38:40 +0100] rev 44252
heptapod-ci: also run the dedicated rust test for the rust code The Rust code has various standard rust test that are fast to run. So let's run them. Differential Revision: https://phab.mercurial-scm.org/D8014
Sat, 16 Nov 2019 12:25:53 +0100 heptapod-ci: run test with python3 too stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 16 Nov 2019 12:25:53 +0100] rev 44251
heptapod-ci: run test with python3 too Python3 is the future^W present, it is important to run tests with it too. Differential Revision: https://phab.mercurial-scm.org/D8013
Fri, 24 Jan 2020 23:22:29 +0100 heptapod-ci: colorize output stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 24 Jan 2020 23:22:29 +0100] rev 44250
heptapod-ci: colorize output The run result are nicer to read with color. Differential Revision: https://phab.mercurial-scm.org/D8012
Sat, 25 Jan 2020 17:57:40 +0100 heptapod-ci: add a basic file to be able to run tests with heptapod stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 25 Jan 2020 17:57:40 +0100] rev 44249
heptapod-ci: add a basic file to be able to run tests with heptapod Having this yaml file somewhere in the main mercurial repository makes it trivial for contributors using heptapod to run CI on their in-progress work. There are alot of different combination (python2/python3 pure/cext/rust/pypy) to be tested and making sure all of them are covered manually is cumbersome. Automatic CI runnig on draft really helps in that matters. We start small bu later changesets will add more step testing more of the variants. The series is targetted on stable to make it available to the widest amount of contribution possible. The definition of the docker files used for this are available here: https://dev.heptapod.net/octobus/ci-dockerfiles Differential Revision: https://phab.mercurial-scm.org/D8011
Tue, 04 Feb 2020 22:07:36 +0100 worker: manually buffer reads from pickle stream stable
Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> [Tue, 04 Feb 2020 22:07:36 +0100] rev 44248
worker: manually buffer reads from pickle stream My previous fix (D8051, cb52e619c99e, which added Python's built-in buffering to the pickle stream) has the problem that the selector will ignore the buffer. When multiple pickled objects are read from the pipe into the buffer at once, only one object will be loaded. This can repeat until the buffer is full and delays the processing of completed items until the worker exits, at which point the pipe is always considered readable and all remaining items are processed. This changeset reverts D8051, removing the buffer again. Instead, on Python 3 only, we use a wrapper to modify the "read" provided to the Unpickler to behave more like a buffered read. We never read more bytes from the pipe than the Unpickler requests, so the selector behaves as expected. Also add a test case for "pickle data was truncated" issue. https://phab.mercurial-scm.org/D8051#119193 Differential Revision: https://phab.mercurial-scm.org/D8076
Thu, 02 Jan 2020 11:04:18 -0800 py3: __repr__ needs to return str, not bytes stable
Kyle Lippincott <spectral@google.com> [Thu, 02 Jan 2020 11:04:18 -0800] rev 44247
py3: __repr__ needs to return str, not bytes Differential Revision: https://phab.mercurial-scm.org/D8089
Tue, 04 Feb 2020 12:07:37 +0100 config: also respect HGRCSKIPREPO in the zeroconf extension stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 04 Feb 2020 12:07:37 +0100] rev 44246
config: also respect HGRCSKIPREPO in the zeroconf extension Differential Revision: https://phab.mercurial-scm.org/D8075
Tue, 04 Feb 2020 12:07:42 +0100 config: also respect HGRCSKIPREPO in hgwebdir_mod stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 04 Feb 2020 12:07:42 +0100] rev 44245
config: also respect HGRCSKIPREPO in hgwebdir_mod Differential Revision: https://phab.mercurial-scm.org/D8074
Mon, 03 Feb 2020 20:41:11 +0100 config: also respect HGRCSKIPREPO in `dispatch._getlocal` stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 03 Feb 2020 20:41:11 +0100] rev 44244
config: also respect HGRCSKIPREPO in `dispatch._getlocal` For some reason, we are also reading the local config in that function. Differential Revision: https://phab.mercurial-scm.org/D8073
Tue, 04 Feb 2020 12:31:19 +0100 config: add a function in `rcutil` to abstract HGRCSKIPREPO stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 04 Feb 2020 12:31:19 +0100] rev 44243
config: add a function in `rcutil` to abstract HGRCSKIPREPO We wil need to respect this environment variable in more place. Differential Revision: https://phab.mercurial-scm.org/D8072
Mon, 03 Feb 2020 20:12:47 -0500 packaging: make the path to Win32 requirements absolute when building WiX stable
Matt Harbison <matt_harbison@yahoo.com> [Mon, 03 Feb 2020 20:12:47 -0500] rev 44242
packaging: make the path to Win32 requirements absolute when building WiX Otherwise this broke automation when not launched from `contrib/packaging`. Differential Revision: https://phab.mercurial-scm.org/D8068
Mon, 03 Feb 2020 11:56:02 -0500 resourceutil: blacken
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 11:56:02 -0500] rev 44241
resourceutil: blacken
Mon, 03 Feb 2020 11:51:52 -0500 merge with stable
Augie Fackler <augie@google.com> [Mon, 03 Feb 2020 11:51:52 -0500] rev 44240
merge with stable
Fri, 31 Jan 2020 10:53:50 -0800 rebase: abort if the user tries to rebase the working copy
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 Jan 2020 10:53:50 -0800] rev 44239
rebase: abort if the user tries to rebase the working copy I think it's more correct to treat `hg rebase -r 'wdir()' -d foo` as `hg co -m foo`, but I'm instead making it error out. That's partly because it's probably what the user wanted (in the case I heard from a user, they had done `hg rebase -s f` where `f` resolved to `wdir()`) and partly because I don't want to think about more complicated cases where the user specifies the working copy together with other commits. Differential Revision: https://phab.mercurial-scm.org/D8057
Fri, 31 Jan 2020 10:41:50 -0800 tests: add tests for rebasing wdir() revision
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 Jan 2020 10:41:50 -0800] rev 44238
tests: add tests for rebasing wdir() revision Differential Revision: https://phab.mercurial-scm.org/D8056
Wed, 22 Jan 2020 13:29:26 -0800 merge: when rename was made on both sides, use ancestor as merge base
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 13:29:26 -0800] rev 44237
merge: when rename was made on both sides, use ancestor as merge base When both sides of a merge have renamed a file to the same place, we would treat that as a "both created" action in merge.py. That means that we'd use an empty diffbase. It seems better to use the copy source as diffbase. That can be done by simply dropping code that prevented us from doing that. I think I did it that way in 57203e0210f8 (copies: calculate mergecopies() based on pathcopies(), 2019-04-11) only to preserve the existing behavior. I also suspect it was just an accident that it behaved that way before that commit. Note that until fa9ad1da2e77 (merge: start using the per-side copy dicts, 2020-01-23), it was non-deterministic (depending on iteration order of the `allsources` set in `copies._fullcopytracing()`) which source was used in the affected test case in test-rename-merge1.t. We could easily have fixed that by sorting them, but now we can instead detect the case (the TODO added in the previous patch). Differential Revision: https://phab.mercurial-scm.org/D7974
Fri, 31 Jan 2020 08:47:32 -0800 absorb: graduate -i flag from experimental
Martin von Zweigbergk <martinvonz@google.com> [Fri, 31 Jan 2020 08:47:32 -0800] rev 44236
absorb: graduate -i flag from experimental The interactive mode seems to work well. I have previously thought that `-i` should be what `-e` does, but the current behavior matches what other `-i` flags do (select a subset of the hunks), so I think that is what we want. Differential Revision: https://phab.mercurial-scm.org/D8055
Sat, 25 Jan 2020 17:30:24 +0900 rust-cpython: remove PySharedRefCell and its companion structs
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Jan 2020 17:30:24 +0900] rev 44235
rust-cpython: remove PySharedRefCell and its companion structs Also updates py_shared_iterator!() documentation accordingly.
Sat, 25 Jan 2020 17:26:23 +0900 rust-cpython: switch to upstreamed version of PySharedRefCell
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Jan 2020 17:26:23 +0900] rev 44234
rust-cpython: switch to upstreamed version of PySharedRefCell Our PyLeaked is identical to cpython::UnsafePyLeaked. I've renamed it because it provides mostly unsafe functions.
Sat, 25 Jan 2020 17:21:06 +0900 rust-cpython: rename inner_shared() to inner()
Yuya Nishihara <yuya@tcha.org> [Sat, 25 Jan 2020 17:21:06 +0900] rev 44233
rust-cpython: rename inner_shared() to inner() The "shared" accessor will be automatically generated, and will have the same name as the data itself.
Fri, 31 Jan 2020 00:08:30 +0900 rust-cpython: use PyList.insert() instead of .insert_item()
Yuya Nishihara <yuya@tcha.org> [Fri, 31 Jan 2020 00:08:30 +0900] rev 44232
rust-cpython: use PyList.insert() instead of .insert_item() Silences the deprecated warning. https://github.com/dgrunwald/rust-cpython/commit/e8cbe864841714c5555db8c90e057bd11e360c7f
Fri, 31 Jan 2020 00:01:29 +0900 rust-cpython: bump cpython to 0.4 to switch to upstreamed PySharedRef
Yuya Nishihara <yuya@tcha.org> [Fri, 31 Jan 2020 00:01:29 +0900] rev 44231
rust-cpython: bump cpython to 0.4 to switch to upstreamed PySharedRef
Thu, 30 Jan 2020 23:57:19 +0900 rust: update dependencies
Yuya Nishihara <yuya@tcha.org> [Thu, 30 Jan 2020 23:57:19 +0900] rev 44230
rust: update dependencies For no particular reason, but just because I'll bump the rust-cpython version.
Mon, 03 Feb 2020 11:07:34 -0500 Added signature for changeset 7f5410dfc8a6 stable
Augie Fackler <raf@durin42.com> [Mon, 03 Feb 2020 11:07:34 -0500] rev 44229
Added signature for changeset 7f5410dfc8a6
Mon, 03 Feb 2020 11:07:33 -0500 Added tag 5.3 for changeset 7f5410dfc8a6 stable
Augie Fackler <raf@durin42.com> [Mon, 03 Feb 2020 11:07:33 -0500] rev 44228
Added tag 5.3 for changeset 7f5410dfc8a6
Wed, 29 Jan 2020 11:11:18 +0100 rust-dirstatemap: add missing @propertycache stable 5.3
Raphaël Gomès <rgomes@octobus.net> [Wed, 29 Jan 2020 11:11:18 +0100] rev 44227
rust-dirstatemap: add missing @propertycache While investigating a regression on `hg update` performance introduced by the Rust `dirstatemap`, two missing `@propertycache` were identified when comparing against the Python implementation. This adds back the first one, that has no observable impact on behavior. The second one (`nonnormalset`) is going to be more involved, as the caching has to be done from the Rust side of things. Differential Revision: https://phab.mercurial-scm.org/D8047
Thu, 30 Jan 2020 19:16:12 +0100 worker: Use buffered input from the pickle stream stable
Jan Alexander Steffens (heftig) <jan.steffens@gmail.com> [Thu, 30 Jan 2020 19:16:12 +0100] rev 44226
worker: Use buffered input from the pickle stream On Python 3, "pickle.load" will raise an exception ("_pickle.UnpicklingError: pickle data was truncated") when it gets a short read, i.e. it receives fewer bytes than it requested. On our build machine, Mercurial seems to frequently hit this problem while updating a mozilla-central clone iff it gets scheduled in batch mode. It is easy to trigger with: #wipe the workdir rm -rf * hg update null chrt -b 0 hg update default I've also written the following program, which demonstrates the core problem: from __future__ import print_function import io import os import pickle import time obj = {"a": 1, "b": 2} obj_data = pickle.dumps(obj) assert len(obj_data) > 10 rfd, wfd = os.pipe() pid = os.fork() if pid == 0: os.close(rfd) for _ in range(4): time.sleep(0.5) print("First write") os.write(wfd, obj_data[:10]) time.sleep(0.5) print("Second write") os.write(wfd, obj_data[10:]) os._exit(0) try: os.close(wfd) rfile = os.fdopen(rfd, "rb", 0) print("Reading") while True: try: obj_copy = pickle.load(rfile) assert obj == obj_copy except EOFError: break print("Success") finally: os.kill(pid, 15) The program reliably fails with Python 3.8 and succeeds with Python 2.7. Providing the unpickler with a buffered reader fixes the issue, so let "os.fdopen" create one. https://bugzilla.mozilla.org/show_bug.cgi?id=1604486 Differential Revision: https://phab.mercurial-scm.org/D8051
Sat, 01 Feb 2020 01:32:28 -0500 packaging: lowercase the `contrib` and `templates` directories with Inno stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 01:32:28 -0500] rev 44225
packaging: lowercase the `contrib` and `templates` directories with Inno I have no idea why these (and `contrib/vim`) were leading with uppercase with Inno, but not WiX. It probably doesn't matter too much, but might be a problem with `templates` if the user enabled case sensitivity on NTFS. Differential Revision: https://phab.mercurial-scm.org/D8063
Sun, 02 Feb 2020 00:56:40 -0500 packaging: merge the requirements.txt files for WiX and Inno stable
Matt Harbison <matt_harbison@yahoo.com> [Sun, 02 Feb 2020 00:56:40 -0500] rev 44224
packaging: merge the requirements.txt files for WiX and Inno Now that the content is common, there's no need to have separate files. The content still differs from the non-Windows platforms though. Differential Revision: https://phab.mercurial-scm.org/D8066
Sat, 01 Feb 2020 00:58:34 -0500 packaging: bundle dulwich, keyring, and pywin32-ctypes with WiX too stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 00:58:34 -0500] rev 44223
packaging: bundle dulwich, keyring, and pywin32-ctypes with WiX too TortoiseHg installs these, which is possibly where they originated (though I would have thought it more likely to be in the WiX installer, given its heritage). When I was working on the TortoiseHg app for Mac (which uses the similar `py2app`), it wasn't possible to use the keyring extension (even externally) without bundling this keyring package into the app. Assuming the same principle applies here, these would enable some common extensions. One of the things that the TortoiseHg packager on macOS does now is it adds the user's local `site-packages` directory to `sys.path`. That would allow the user to install these critical modules in cases like this. But that can probably wait for py3 packaging. The only difference in the installed packages that I see now is WiX also bundles distutils for some reason. I suppose that's not harming anything, so I'm not touching it. The only orphans in the install directories when comparing WiX and Inno now is the Copying.txt vs COPYING.rtf, the two uninstaller files for Inno, and a `Mercurial.url` file in Inno. I have no idea what that is, and it has *.ini syntax with a single field pointing to the Mercurial homepage. Differential Revision: https://phab.mercurial-scm.org/D8062
Sat, 01 Feb 2020 00:48:08 -0500 packaging: bundle the default mercurial.ini template with Inno also stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 00:48:08 -0500] rev 44222
packaging: bundle the default mercurial.ini template with Inno also This is a step towards converging on the same installer content on Windows. Differential Revision: https://phab.mercurial-scm.org/D8061
Sat, 01 Feb 2020 00:41:37 -0500 packaging: set the FileVersion field in the Inno installer executable stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 00:41:37 -0500] rev 44221
packaging: set the FileVersion field in the Inno installer executable Previously, Properties > Details > File version showed "0.0.0.0". This appears to be a longstanding issue, and not part of the refactoring this cycle. Differential Revision: https://phab.mercurial-scm.org/D8060
Sat, 01 Feb 2020 00:32:46 -0500 packaging: move the version normalization function to the util module stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 01 Feb 2020 00:32:46 -0500] rev 44220
packaging: move the version normalization function to the util module This will be used with Inno as well. Since this module isn't platform specific, rename to include that this is meant for Windows. (Mac has a different format.) Differential Revision: https://phab.mercurial-scm.org/D8059
Fri, 31 Jan 2020 22:20:39 -0500 resourceutil: account for the non-resource-like file hierarchy under py2exe stable
Matt Harbison <matt_harbison@yahoo.com> [Fri, 31 Jan 2020 22:20:39 -0500] rev 44219
resourceutil: account for the non-resource-like file hierarchy under py2exe After 9e367157a990, config files for py2exe were expected to be in C:\Program Files\Mercurial\mercurial\defaultrc because of the implied resource structure of 'mercurial.defaultrc.*.rc', relative to the executable. Accomodating this would require changes to the WIX and Inno scripts (and perhaps the script that generates the WIX script), as well as 3rd party bundlers like TortoiseHg. But these files aren't read as resources anyway- they fall back to the filesystem APIs. (If we really wanted to carry on the charade, the installer would have to also sprinkle various empty __init__.py files around.) Instead, this simply prunes the 'mercurial.' portion of the resource name when run with py2exe. (PyOxidizer uses the resources API, not the filesystem fallback, so it is unaffected.) Since this hack only affects the py2 Windows installers and is less risky, I think it's reasonable. We haven't needed to load any 3rd party resource up to this point, and would have to make packaging changes anyway to handle that. Differential Revision: https://phab.mercurial-scm.org/D8058
Thu, 30 Jan 2020 19:37:06 -0500 wix: restore COPYING.rtf stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Jan 2020 19:37:06 -0500] rev 44218
wix: restore COPYING.rtf This got truncated to 0 bytes in 0ab651b5f77c when the Phabricator extension crashed because it's a binary file. That caused the license page in the WIX installer to be empty. I don't remember if I needed to resubmit after the bug was fixed, so let's try this again with the current stable. If this fails, I'll retry with 5.1 to see if this is a regression in the API changeover last cycle. Differential Revision: https://phab.mercurial-scm.org/D8052
Fri, 24 Jan 2020 12:50:27 +0100 contrib: a small script to nudge lingering diff
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 24 Jan 2020 12:50:27 +0100] rev 44217
contrib: a small script to nudge lingering diff After a discussion on IRC with various reviewers. It seems like a good idea to have some automatic cleanup of old, inactive diffs. Here is a small script able to do so. I am preparing to unleash it on our phabricator instance.
Sun, 26 Jan 2020 16:23:57 -0800 packaging: add support for PyOxidizer
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 26 Jan 2020 16:23:57 -0800] rev 44216
packaging: add support for PyOxidizer I've successfully built Mercurial on the development tip of PyOxidizer on Linux and Windows. It mostly "just works" on Linux. Windows is a bit more finicky. In-memory resource files are probably not all working correctly due to bugs in PyOxidizer's naming of modules. PyOxidizer now now supports installing files next to the produced binary. (We do this for templates in the added file.) So a workaround should be available. Also, since the last time I submitted support for PyOxidizer, PyOxidizer gained the ability to auto-generate Rust projects to build executables. So we don't need to worry about vendoring any Rust code to initially support PyOxidizer. However, at some point we will likely want to write our own command line driver that embeds a Python interpreter via PyOxidizer so we can run Rust code outside the confines of a Python interpreter. But that will be a follow-up. I would also like to add packaging.py CLI commands to build PyOxidizer distributions. This can come later, if ever. PyOxidizer's new "targets" feature makes it really easy to define packaging tasks in its Starlark configuration file. While not much is implemented yet, eventually we should be able to produce MSIs, etc using a `pyoxidizer build` one-liner. We'll get there... Differential Revision: https://phab.mercurial-scm.org/D7450
Wed, 29 Jan 2020 11:30:16 -0800 mergestate: add accessors for local and other nodeid, not just contexts
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 11:30:16 -0800] rev 44215
mergestate: add accessors for local and other nodeid, not just contexts The mergestate can contain invalid nodeids. In that case, `mergestate.localctx` or `mergestate.otherctx` will fail. This patch provides a way of accessing the nodeid without failing in such cases. Differential Revision: https://phab.mercurial-scm.org/D8040
Wed, 15 Jan 2020 22:24:16 -0800 rebase: define base in only place in defineparents()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 22:24:16 -0800] rev 44214
rebase: define base in only place in defineparents() Just a little refactoring to prepare for the next patch. Differential Revision: https://phab.mercurial-scm.org/D7906
Fri, 20 Dec 2019 16:16:57 -0800 tests: use full `uncommit` command name in tests
Martin von Zweigbergk <martinvonz@google.com> [Fri, 20 Dec 2019 16:16:57 -0800] rev 44213
tests: use full `uncommit` command name in tests I'm about to add a `hg uncopy`, so the `hg unc` we used for `hg uncommit` would become ambiguous. Differential Revision: https://phab.mercurial-scm.org/D8028
Tue, 28 Jan 2020 14:53:23 -0800 graft: default `base` argument to common case of `ctx.p1()`
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 14:53:23 -0800] rev 44212
graft: default `base` argument to common case of `ctx.p1()` I also updated the callers that wanted that, partly to simplify and partly to show that it works. Differential Revision: https://phab.mercurial-scm.org/D8027
Fri, 10 Jan 2020 13:12:24 -0800 graft: let caller pass in overlayworkingctx to merge.graft()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 13:12:24 -0800] rev 44211
graft: let caller pass in overlayworkingctx to merge.graft() Passing in a different `wctx` than `repo[None]` is useful because it allows the caller to decide to not touch the working directory. Differential Revision: https://phab.mercurial-scm.org/D8026
Wed, 29 Jan 2020 23:14:31 -0800 copies: fix crash when copy source is not in graft base
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 23:14:31 -0800] rev 44210
copies: fix crash when copy source is not in graft base Differential Revision: https://phab.mercurial-scm.org/D8046
Wed, 29 Jan 2020 23:05:02 -0800 tests: add test showing crash when shelving ghosted rename target
Martin von Zweigbergk <martinvonz@google.com> [Wed, 29 Jan 2020 23:05:02 -0800] rev 44209
tests: add test showing crash when shelving ghosted rename target When you `hg rename` a file and then delete the rename target, `hg shelve` will give you a traceback. Note that the shelve succeeds and the shelve is correct, it's just the update to the parent that fails (i.e. to the parent of the commit that was created for the shelve). This can be squashed into the next commit if the reviewer prefers. Differential Revision: https://phab.mercurial-scm.org/D8045
Thu, 30 Jan 2020 23:48:45 -0500 resourceutil: correct the root path for file based lookup under py2exe stable
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Jan 2020 23:48:45 -0500] rev 44208
resourceutil: correct the root path for file based lookup under py2exe This silly copy/paste error caused "Mercurial" to be truncated from "C:\Program Files". The fact that "helptext" and "defaultrc" are now in a subpackage of "mercurial" added it back on, and everything seemed to work. But that broke if not installed to the default directory, and also caused TortoiseHg to look at Mercurial's config files instead of its own. Differential Revision: https://phab.mercurial-scm.org/D8054
Tue, 22 Oct 2019 16:04:34 +0900 rust-cpython: mark all PyLeaked methods as unsafe
Yuya Nishihara <yuya@tcha.org> [Tue, 22 Oct 2019 16:04:34 +0900] rev 44207
rust-cpython: mark all PyLeaked methods as unsafe Unfortunately, these methods can be abused to obtain the inner 'static reference. The simplest (pseudo-code) example is: let leaked: PyLeaked<&'static _> = shared.leak_immutable(); let static_ref: &'static _ = &*leaked.try_borrow(py)?; // PyLeakedRef::deref() tries to bound the lifetime to itself, but // the underlying data is a &'static reference, so the returned // reference can be &'static. This problem can be easily fixed by coercing the lifetime, but there are many other ways to achieve that, and there wouldn't be a generic solution: let leaked: PyLeaked<&'static [_]> = shared.leak_immutable(); let leaked_iter: PyLeaked<slice::Iter<'static, _>> = unsafe { leaked.map(|v| v.iter()) }; let static_slice: &'static [_] = leaked_iter.try_borrow(py)?.as_slice(); So basically I failed to design the safe borrowing interface. Maybe we'll instead have to add much more restricted interface on top of the unsafe PyLeaked methods? For instance, Iterator::next() could be implemented if its Item type is not &'a (where 'a may be cheated.) Anyway, this seems not an easy issue, so it's probably better to leave the current interface as unsafe, and get broader comments while upstreaming this feature.
Sat, 19 Oct 2019 17:01:28 +0900 rust-cpython: make PySharedRef::try_borrow_mut() return BorrowMutError
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 17:01:28 +0900] rev 44206
rust-cpython: make PySharedRef::try_borrow_mut() return BorrowMutError As I said, it shouldn't be an error of Python layer, but is something like a coding error. Returning BorrowMutError makes more sense. There's a weird hack to propagate the borrow-by-leaked state to RefCell to obtain BorrowMutError. If we don't like it, maybe we can add our own BorrowMutError.
Sat, 19 Oct 2019 16:48:34 +0900 rust-cpython: inline PySharedState::leak_immutable() and PyLeaked::new()
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 16:48:34 +0900] rev 44205
rust-cpython: inline PySharedState::leak_immutable() and PyLeaked::new() For the same reason as the previous patch. The unsafe stuff can be better documented if these functions are inlined.
Sat, 19 Oct 2019 16:34:02 +0900 rust-cpython: inline PySharedState::try_borrow_mut()
Yuya Nishihara <yuya@tcha.org> [Sat, 19 Oct 2019 16:34:02 +0900] rev 44204
rust-cpython: inline PySharedState::try_borrow_mut() Since the core borrowing/leaking logic has been moved to PySharedRef* and PyLeaked*, it doesn't make sense that PySharedState had a function named "try_borrow_mut". Let's turn it into a pure data struct.
Sat, 12 Oct 2019 23:34:05 +0900 rust-cpython: add panicking version of borrow_mut() and use it
Yuya Nishihara <yuya@tcha.org> [Sat, 12 Oct 2019 23:34:05 +0900] rev 44203
rust-cpython: add panicking version of borrow_mut() and use it The original borrow_mut() is renamed to try_borrow_mut(). Since leak_immutable() no longer incref the borrow count, the caller should know if the underlying value is borrowed or not. No Python world is involved. That's why we can simply use the panicking borrow_mut().
Tue, 28 Jan 2020 22:27:30 -0500 setup: don't skip the search for global hg.exe if there is no local instance
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:27:30 -0500] rev 44202
setup: don't skip the search for global hg.exe if there is no local instance The point of trying not to blindly execute `hg` on Windows is that the local hg.exe would be given precedence, and if py3 isn't on PATH, it errors out with a modal dialog. But that's not a problem if there is no local executable that could be run. The problem that I recently ran into was I upgraded the repo format to use zstd. But doing a `make clean` deletes all of the supporting libraries, causing the next run to abort with a message about not understanding the `revlog-compression-zstd` requirement. By getting rid of the local executable in the previous commit when cleaning, we avoid leaving a broken executable around, and avoid the py3 PATH problem too. There is still a small hole in that `hg.exe` needs to be deleted before switching between py2/py3/PyOxidizer builds, because the zstd module won't load. But that seems like good hygiene anyway. Differential Revision: https://phab.mercurial-scm.org/D8038
Tue, 28 Jan 2020 22:35:08 -0500 make: also delete hg.exe when cleaning
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:35:08 -0500] rev 44201
make: also delete hg.exe when cleaning This will be needed for the next patch, which has more details. It has to come before the call into setup.py because even `python setup.py clean` calls hg to generate the version file. Differential Revision: https://phab.mercurial-scm.org/D8037
Thu, 23 Jan 2020 15:44:30 -0800 merge: start using the per-side copy dicts
Martin von Zweigbergk <martinvonz@google.com> [Thu, 23 Jan 2020 15:44:30 -0800] rev 44200
merge: start using the per-side copy dicts The point of this patch is mostly to clarify `manifestmerge()`. I find it much easier to reason about now. Differential Revision: https://phab.mercurial-scm.org/D7990
Wed, 22 Jan 2020 14:35:30 -0800 copies: define a type to return from mergecopies()
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 14:35:30 -0800] rev 44199
copies: define a type to return from mergecopies() We'll soon return two instances of many of the dicts from `copies.mergecopies()`. That will mean that we need to return 9 different dicts, which is clearly not manageable. This patch instead encapsulates the 4 dicts we'll duplicate in a new type. For now, we still just return one instance of it (plus the separate `diverge` dict). Differential Revision: https://phab.mercurial-scm.org/D7989
Wed, 22 Jan 2020 16:45:56 -0800 merge: move initialization of copy dicts to one place
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 16:45:56 -0800] rev 44198
merge: move initialization of copy dicts to one place Differential Revision: https://phab.mercurial-scm.org/D7988
Fri, 24 Jan 2020 10:39:55 -0800 copies: print debug information about copies per side/branch
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 10:39:55 -0800] rev 44197
copies: print debug information about copies per side/branch Differential Revision: https://phab.mercurial-scm.org/D7987
Wed, 22 Jan 2020 15:31:17 -0800 copies: make mergecopies() distinguish between copies on each side
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 15:31:17 -0800] rev 44196
copies: make mergecopies() distinguish between copies on each side I find it confusing that most of the dicts returned from `mergecopies()` have entries specific to one branch of the merge, but they're still combined into dict. For example, you can't tell if `copy = {"bar": "foo"}` means that "foo" was copied to "bar" on the first branch or the second. It also feels like there are bugs lurking here because we may mistake which side the copy happened on. However, for most of the dicts, it's not possible that there is disagreement. For example, `renamedelete` keeps track of renames that happened on one side of the merge where the other side deleted the file. There can't be a disagreement there (because we record that in the `diverge` dict instead). For regular copies/renames, there can be a disagreement. Let's say file "foo" was copied to "bar" on one branch and file "baz" was copied to "bar" on the other. Beacause we only return one `copy` dict, we end up replacing the `{"bar": "foo"}` entry by `{"bar": "baz"}`. The merge code (`manifestmerge()`) will then decide that that means "both renamed from 'baz'". We should probably treat it as a conflict instead. The next few patches will make `mergecopies()` return two instances of most of the returned copies. That will lead to a bit more code (~40 lines), but I think it makes both `copies.mergecopies()` and `merge.manifestmerge()` clearer. Differential Revision: https://phab.mercurial-scm.org/D7986
Fri, 24 Jan 2020 17:25:40 -0800 pathutil: mark parent directories as audited as we go
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 17:25:40 -0800] rev 44195
pathutil: mark parent directories as audited as we go Before 0b7ce0b16d8a (pathauditor: change parts verification order to be root first, 2016-02-11), we used to validate child directories before parents. It was then important to only mark the child audited only after we had audited its parent (ancestors). I'm pretty sure we don't need to do that any more, now that we audit parents before children. Differential Revision: https://phab.mercurial-scm.org/D8002
Mon, 27 Jan 2020 09:14:19 -0800 cmdutil: change check_incompatible_arguments() *arg to single iterable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 27 Jan 2020 09:14:19 -0800] rev 44194
cmdutil: change check_incompatible_arguments() *arg to single iterable This makes it clearer on the call-sites that the first argument is special. Thanks to Yuya for the suggestion. Differential Revision: https://phab.mercurial-scm.org/D8018
Mon, 27 Jan 2020 12:38:59 -0800 rust: remove an unnecessary set of parentheses
Martin von Zweigbergk <martinvonz@google.com> [Mon, 27 Jan 2020 12:38:59 -0800] rev 44193
rust: remove an unnecessary set of parentheses My build complained about this. I guess it started after I upgraded rustc. Differential Revision: https://phab.mercurial-scm.org/D8020
Mon, 27 Jan 2020 18:16:05 -0800 profiling: flush stdout before writing profile to stderr
Kyle Lippincott <spectral@google.com> [Mon, 27 Jan 2020 18:16:05 -0800] rev 44192
profiling: flush stdout before writing profile to stderr On py3, stdout and stderr appear to be buffered and this causes my command's output to be intermixed with the profiling output. Differential Revision: https://phab.mercurial-scm.org/D8024
Tue, 28 Jan 2020 10:40:19 -0800 rust: re-format with nightly rustfmt
Martin von Zweigbergk <martinvonz@google.com> [Tue, 28 Jan 2020 10:40:19 -0800] rev 44191
rust: re-format with nightly rustfmt This fixes test-check-rust-format.t. Differential Revision: https://phab.mercurial-scm.org/D8025
Tue, 28 Jan 2020 22:03:00 -0500 tests: stablize test-rename-merge1.t on Windows
Matt Harbison <matt_harbison@yahoo.com> [Tue, 28 Jan 2020 22:03:00 -0500] rev 44190
tests: stablize test-rename-merge1.t on Windows This goes with d7622fdec3b5. Differential Revision: https://phab.mercurial-scm.org/D8036
Sat, 21 Sep 2019 17:27:14 +0900 rust-cpython: make sure PySharedRef::borrow_mut() never panics
Yuya Nishihara <yuya@tcha.org> [Sat, 21 Sep 2019 17:27:14 +0900] rev 44189
rust-cpython: make sure PySharedRef::borrow_mut() never panics Since it returns a Result, it shouldn't panic depending on where the borrowing fails. PySharedRef::borrow_mut() will be renamed to try_borrow_mut() by the next patch.
Tue, 22 Oct 2019 11:38:43 +0900 rust-cpython: remove useless wrappers from PyLeaked, just move by map()
Yuya Nishihara <yuya@tcha.org> [Tue, 22 Oct 2019 11:38:43 +0900] rev 44188
rust-cpython: remove useless wrappers from PyLeaked, just move by map() This series prepares for migrating to the upstreamed version of PySharedRef. I found this last batch wasn't queued while rewriting the callers. While Option<T> was historically needed, it shouldn't be required anymore. I wasn't aware that each filed can be just moved.
Mon, 27 Jan 2020 20:28:47 +0100 rust-node: avoid meaningless read at the end of odd prefix
Georges Racinet <georges.racinet@octobus.net> [Mon, 27 Jan 2020 20:28:47 +0100] rev 44187
rust-node: avoid meaningless read at the end of odd prefix This should be heavily factored out by the CPU branch predictor anyway. Differential Revision: https://phab.mercurial-scm.org/D8019
Fri, 27 Dec 2019 16:06:54 +0100 rust-nodemap: generic NodeTreeVisitor
Georges Racinet <georges.racinet@octobus.net> [Fri, 27 Dec 2019 16:06:54 +0100] rev 44186
rust-nodemap: generic NodeTreeVisitor This iterator will help avoid code duplication when we'll implement `insert()`, in which we will need to traverse the node tree, and to remember the visited blocks. The structured iterator item will allow different usages from `lookup()` and the upcoming `insert()`. Differential Revision: https://phab.mercurial-scm.org/D7794
Fri, 27 Dec 2019 15:11:43 +0100 rust-nodemap: mutable NodeTree data structure
Georges Racinet <georges.racinet@octobus.net> [Fri, 27 Dec 2019 15:11:43 +0100] rev 44185
rust-nodemap: mutable NodeTree data structure Thanks to the previously indexing abstraction, the only difference in the lookup algorithm is that we don't need the special case for an empty NodeTree any more. We've considered making the mutable root an `Option<Block>`, but that leads to unpleasant checks and `unwrap()` unless we abstract it as typestate patterns (`NodeTree<Immutable>` and `NodeTree<Mutated>`) which seem exaggerated in that case. The initial copy of the root block is a very minor performance penalty, given that it typically occurs just once per transaction. Differential Revision: https://phab.mercurial-scm.org/D7793
Thu, 26 Dec 2019 15:47:14 +0100 rust-nodemap: abstracting the indexing
Georges Racinet <georges.racinet@octobus.net> [Thu, 26 Dec 2019 15:47:14 +0100] rev 44184
rust-nodemap: abstracting the indexing In the forthcoming mutable implementation, we'll have to visit node trees that are more complex than a single slice, although the algorithm will still be expressed in simple indexing terms. We still refrain using `#[inline]` indications as being premature optimizations, but we strongly hope the compiler will indeed inline most of the glue. Differential Revision: https://phab.mercurial-scm.org/D7792
Thu, 23 Jan 2020 17:18:13 +0100 rust-nodemap: NodeMap trait with simplest implementation
Georges Racinet <georges.racinet@octobus.net> [Thu, 23 Jan 2020 17:18:13 +0100] rev 44183
rust-nodemap: NodeMap trait with simplest implementation We're defining here only a small part of the immutable methods it will have at the end. This is so we can focus in the following changesets on the needed abstractions for a mutable append-only serializable version. The first implementor exposes the actual lookup algorithm in its simplest form. It will have to be expanded to account for the missing methods, and the special cases related to NULL_NODE. Differential Revision: https://phab.mercurial-scm.org/D7791
Fri, 27 Dec 2019 23:04:18 +0100 rust-node: handling binary Node prefix
Georges Racinet <georges.racinet@octobus.net> [Fri, 27 Dec 2019 23:04:18 +0100] rev 44182
rust-node: handling binary Node prefix Parallel to the inner signatures of the nodetree functions in revlog.c, we'll have to handle prefixes of `Node` in binary form. Another motivation is that it allows to convert from full Node references to `NodePrefixRef` without copy. This is expected to be by far the most common case in practice. There's a slight complication due to the fact that we'll be sometimes interested in prefixes with an odd number of hexadecimal digits, which translates in binary form by a last byte in which only the highest weight 4 bits are considered. This is totally transparent for callers and could be revised once we have proper means to measure performance. The C implementation does the same, passing the length in nybbles as function arguments. Because Rust byte slices already have a length, we carry the even/odd informaton as a boolean, to avoid introducing logical redundancies and the related potential inconsistency bugs. There are a few candidates for inlining here, but we refrain from such premature optimizations, letting the compiler decide. Differential Revision: https://phab.mercurial-scm.org/D7790
Wed, 22 Jan 2020 16:35:56 +0100 rust-revlog: a trait for the revlog index
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:35:56 +0100] rev 44181
rust-revlog: a trait for the revlog index As explained in the doc comment, this is the minimum needed for our immediate concern, which is to implement a nodemap in Rust. The trait will be later implemented in `hg-cpython` by the index Python object implemented in C, thanks to exposition of the corresponding functions as a capsule. The `None` return cases in `node()` match what the `index_node()` C function does. Differential Revision: https://phab.mercurial-scm.org/D7789
Fri, 24 Jan 2020 17:10:45 -0800 pathauditor: drop a redundant call to bytes.lower()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 17:10:45 -0800] rev 44180
pathauditor: drop a redundant call to bytes.lower() `_lowerclean(s)` calls `s.lower()`, so we don't need to do that before calling it. Differential Revision: https://phab.mercurial-scm.org/D8001
Fri, 24 Jan 2020 15:18:19 -0800 merge: replace a repo.lookup('.') by more typical repo['.'].node()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 15:18:19 -0800] rev 44179
merge: replace a repo.lookup('.') by more typical repo['.'].node() The `repo.lookup('.')` form comes from b3311e26f94f (merge: fix --preview to show all nodes that will be merged (issue2043)., 2010-02-15). I don't know why that commit changed from `repo['.']`, but I don't think there's any reason to do that. Note that performance should not be a reason (anymore?), because repo.lookup() is implemented by first creating a context object. Differential Revision: https://phab.mercurial-scm.org/D7998
Fri, 24 Jan 2020 16:07:42 -0800 merge: drop now-unused "abort" argument from hg.merge()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 16:07:42 -0800] rev 44178
merge: drop now-unused "abort" argument from hg.merge() Differential Revision: https://phab.mercurial-scm.org/D7997
Fri, 24 Jan 2020 17:49:21 -0800 merge: don't auto-pick destination with `hg merge 'wdir()'`
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 17:49:21 -0800] rev 44177
merge: don't auto-pick destination with `hg merge 'wdir()'` If the user doesn't specify a commit to merge with, we'll have `node==None` in `commands.merge()`. We'll then try to find a good commit to merge with. However, if the user, for some strange reason, runs `hg merge 'wdir()'`, we'll also have `node==None` and we'll do that same. That's clearly not the intent, so let's not do that. It turns out we'd instead crash on that command after this patch, so I added special handling of it too. Differential Revision: https://phab.mercurial-scm.org/D7996
Fri, 24 Jan 2020 16:05:11 -0800 merge: call hg.abortmerge() directly and return early
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 16:05:11 -0800] rev 44176
merge: call hg.abortmerge() directly and return early It's seem really weird to go through a lot of unrelated code before we call `hg.merge(..., abort=True)` when we can just call `hg.abortmerge()` and return early. Differential Revision: https://phab.mercurial-scm.org/D7995
Fri, 24 Jan 2020 16:00:54 -0800 merge: check that there are no conflicts after --abort
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 16:00:54 -0800] rev 44175
merge: check that there are no conflicts after --abort Same idea as in abcc82bf0717 (clean: check that there are no conflicts after, 2020-01-24). We should reuse more code here, but that will come later. Differential Revision: https://phab.mercurial-scm.org/D7994
Fri, 24 Jan 2020 15:07:44 -0800 merge: use check_incompatible_arguments() for --abort
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 15:07:44 -0800] rev 44174
merge: use check_incompatible_arguments() for --abort Differential Revision: https://phab.mercurial-scm.org/D7993
Fri, 24 Jan 2020 20:27:59 -0800 wix: use original version string for MSI filename stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Jan 2020 20:27:59 -0800] rev 44173
wix: use original version string for MSI filename Version string normalization is mostly to placate MSI requirements. I think it makes sense to use the original version string in filenames. Since we can have distinct versions normalizing to the same MSI version string, this will allow us to distinguish between different actual version strings based on the filename. Differential Revision: https://phab.mercurial-scm.org/D8005
Fri, 24 Jan 2020 20:24:29 -0800 wix: always normalize version string stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Jan 2020 20:24:29 -0800] rev 44172
wix: always normalize version string Before, it was possible to pass in a custom version string which would not be valid in MSI. So we always normalize the version string. While we're here, also print when we normalize the version string, for better visibility. Differential Revision: https://phab.mercurial-scm.org/D8004
Fri, 24 Jan 2020 20:21:53 -0800 wix: more robust normalization of RC version components stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Jan 2020 20:21:53 -0800] rev 44171
wix: more robust normalization of RC version components MSI has strict version requirements where the format is `A.B.C[.D]` and all fields must be numeric (https://docs.microsoft.com/en-us/windows/win32/msi/productversion?redirectedfrom=MSDN). Only the first 3 are used by the installer itself. Mercurial's version strings can have `rcN` and an optional `+<commit>-<date>` fragment at the end. This commit teaches the MSI version normalization to handle both of these more robustly. Before, we would throw away the `.rcN` component completely. e.g. `5.3rc1` would get normalized to `5.3.0`. And worse, `5.3rc0+5-abcdef` would get normalized to `5.3.5`. After this commit, presence of an `.rcN` provides the value for a 4th field. e.g. `5.3rc1` -> `5.3.0.1`. In addition, the commit count from the `+` suffix gets normalized into the 4th version component, but only if the original version string didn't have a 4th version component or if no `rcN` is present. e.g. `5.3+5-abcdef` is `5.3.0.5`. Differential Revision: https://phab.mercurial-scm.org/D8003
Sat, 25 Jan 2020 00:16:04 -0500 copyright: update to 2020 stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Jan 2020 00:16:04 -0500] rev 44170
copyright: update to 2020 Differential Revision: https://phab.mercurial-scm.org/D8006
Sat, 25 Jan 2020 01:06:46 -0500 phabricator: fix a crash when submitting binaries (issue6260) stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Jan 2020 01:06:46 -0500] rev 44169
phabricator: fix a crash when submitting binaries (issue6260) I think this assumed that `p1()` returned the changectx instead of the previous filelog entry. Differential Revision: https://phab.mercurial-scm.org/D8010
Wed, 15 Jan 2020 17:15:45 -0800 rebase: move some variables after an error cases where they're not needed
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 17:15:45 -0800] rev 44168
rebase: move some variables after an error cases where they're not needed Differential Revision: https://phab.mercurial-scm.org/D7905
Wed, 15 Jan 2020 10:44:23 -0800 rebase: clarify a little by calculating a set in Python instead of in revset
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 10:44:23 -0800] rev 44167
rebase: clarify a little by calculating a set in Python instead of in revset By calculating the set in Python, we can give it a name, which helps readability. Differential Revision: https://phab.mercurial-scm.org/D7904
Wed, 15 Jan 2020 15:12:50 -0800 merge: avoid a negation in the definition of updatedirstate
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:12:50 -0800] rev 44166
merge: avoid a negation in the definition of updatedirstate We only use `partial` in one place: the definition of `updatedirstate`. Let's simplify that a little. Differential Revision: https://phab.mercurial-scm.org/D7900
Fri, 24 Jan 2020 08:32:35 -0800 merge: move definition of `partial` closer to where it's used
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 08:32:35 -0800] rev 44165
merge: move definition of `partial` closer to where it's used Differential Revision: https://phab.mercurial-scm.org/D7983
Wed, 22 Jan 2020 13:06:56 -0800 copies: extract function for finding directory renames
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 13:06:56 -0800] rev 44164
copies: extract function for finding directory renames The directory rename code is logically quite isolated, so it makes sense to make it physically isolated as well. Differential Revision: https://phab.mercurial-scm.org/D7977
Wed, 22 Jan 2020 15:23:30 -0800 copies: avoid calculating debug-only stuff without --debug
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 15:23:30 -0800] rev 44163
copies: avoid calculating debug-only stuff without --debug `renamedeleteset` and `divergeset` is only used with `repo.ui.debugflag`, so let's avoid calculating them otherwise. While at it, I also added a `del renamedeleteset` for consistency. Differential Revision: https://phab.mercurial-scm.org/D7976
Wed, 22 Jan 2020 15:20:12 -0800 copies: move early return in mergecopies() earlier
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jan 2020 15:20:12 -0800] rev 44162
copies: move early return in mergecopies() earlier It wasn't obvious that the early return happened only when there are no copies. That is the case, however, because if `fullcopy` is empty, then so is `copies1` and `copies2`, and then so is `inversecopies1` and `inversecopies2`, and then so is `allsources`, and then so is `copy`, `diverge` and `renamedelete`. By moving the early return earlier, we also avoid calculating the set of added files from the base to each side. Differential Revision: https://phab.mercurial-scm.org/D7975
Fri, 24 Jan 2020 07:00:45 -0800 tests: test merge of renames of different sources to same target
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 07:00:45 -0800] rev 44161
tests: test merge of renames of different sources to same target This is a really obscure scenario, but let's still have it tested so we know when it changes. Differential Revision: https://phab.mercurial-scm.org/D7985
Fri, 24 Jan 2020 09:33:02 -0800 clean: check that there are no conflicts after
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 09:33:02 -0800] rev 44160
clean: check that there are no conflicts after As noted by Pulkit, there should never be any conflicts after doing a clean update, so `hg.clean()` should never return `True`. Let's check that assertion instead to clarify the code. The callers will now get a `None` instead of a `False` returned, but that should be fine (both result in a 0 exit status). Differential Revision: https://phab.mercurial-scm.org/D7984
Fri, 24 Jan 2020 14:32:53 -0800 progress: delete deprecated ui.progress()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jan 2020 14:32:53 -0800] rev 44159
progress: delete deprecated ui.progress() Differential Revision: https://phab.mercurial-scm.org/D7991
Fri, 17 Jan 2020 15:34:11 +0100 rust-dependencies: update rayon
Raphaël Gomès <rgomes@octobus.net> [Fri, 17 Jan 2020 15:34:11 +0100] rev 44158
rust-dependencies: update rayon This is just to make sure we use the latest version and also makes it easier to peruse the docs. Differential Revision: https://phab.mercurial-scm.org/D7926
Wed, 22 Jan 2020 20:01:38 -0800 packaging: add configparser to inno requirements file stable
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 22 Jan 2020 20:01:38 -0800] rev 44157
packaging: add configparser to inno requirements file This dependency is missing and pip complains about it in strict hashing mode. How this was missed, I have no clue. Differential Revision: https://phab.mercurial-scm.org/D7973
Fri, 24 Jan 2020 11:05:42 -0500 merge with stable
Augie Fackler <augie@google.com> [Fri, 24 Jan 2020 11:05:42 -0500] rev 44156
merge with stable
Fri, 24 Jan 2020 11:02:59 -0500 Added signature for changeset e4344e463c0c stable
Augie Fackler <raf@durin42.com> [Fri, 24 Jan 2020 11:02:59 -0500] rev 44155
Added signature for changeset e4344e463c0c
Fri, 24 Jan 2020 11:02:58 -0500 Added tag 5.3rc1 for changeset e4344e463c0c stable
Augie Fackler <raf@durin42.com> [Fri, 24 Jan 2020 11:02:58 -0500] rev 44154
Added tag 5.3rc1 for changeset e4344e463c0c
Fri, 24 Jan 2020 01:37:18 -0500 packaging: rename hgrc.d to defaultrc for Windows config files next to the exe stable 5.3rc1
Matt Harbison <matt_harbison@yahoo.com> [Fri, 24 Jan 2020 01:37:18 -0500] rev 44153
packaging: rename hgrc.d to defaultrc for Windows config files next to the exe The code and the help still says that it will read hgrc.d next to the executable. But this directory needs to exist to read the resource based config files. Otherwise even `hg version` errors out: $ /c/Program\ Files/Mercurial/hg.exe version Traceback (most recent call last): File "hg", line 43, in <module> File "mercurial\dispatch.pyc", line 110, in run File "mercurial\dispatch.pyc", line 226, in dispatch File "mercurial\ui.pyc", line 308, in load File "mercurial\rcutil.pyc", line 99, in rccomponents File "mercurial\rcutil.pyc", line 69, in default_rc_resources File "mercurial\utils\resourceutil.pyc", line 84, in contents WindowsError: [Error 3] The system cannot find the path specified: 'c:\\Program Files\\mercurial\\defaultrc\\*.*' Differential Revision: https://phab.mercurial-scm.org/D7981
Fri, 24 Jan 2020 01:11:19 -0500 resourceutil: ensure `_rootpath` is defined under py2exe stable
Matt Harbison <matt_harbison@yahoo.com> [Fri, 24 Jan 2020 01:11:19 -0500] rev 44152
resourceutil: ensure `_rootpath` is defined under py2exe Can't even run `hg version` without this. Differential Revision: https://phab.mercurial-scm.org/D7980
Wed, 15 Jan 2020 15:08:42 -0800 merge: define updatedirstate a little earlier and reuse it
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:08:42 -0800] rev 44151
merge: define updatedirstate a little earlier and reuse it Differential Revision: https://phab.mercurial-scm.org/D7899
Wed, 15 Jan 2020 15:07:43 -0800 merge: don't call update hook when using in-memory context
Martin von Zweigbergk <martinvonz@google.com> [Wed, 15 Jan 2020 15:07:43 -0800] rev 44150
merge: don't call update hook when using in-memory context I'm pretty sure many hook implementors will assume that they can inspect the working copy and/or dirstate parents when the hook is called, so I don't think we should call the hook when using an in-memory context. The new behavior matches that of the preupdate hook. Differential Revision: https://phab.mercurial-scm.org/D7898
Thu, 23 Jan 2020 13:10:48 -0800 merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 23 Jan 2020 13:10:48 -0800] rev 44149
merge with stable
Wed, 22 Jan 2020 20:01:38 -0800 packaging: add configparser to inno requirements file
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 22 Jan 2020 20:01:38 -0800] rev 44148
packaging: add configparser to inno requirements file This dependency is missing and pip complains about it in strict hashing mode. How this was missed, I have no clue. Differential Revision: https://phab.mercurial-scm.org/D7973
Wed, 22 Jan 2020 22:23:04 -0800 python-zstandard: blacken at 80 characters
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 22 Jan 2020 22:23:04 -0800] rev 44147
python-zstandard: blacken at 80 characters I made this change upstream and it will make it into the next release of python-zstandard. I figured I'd send it Mercurial's way because it will allow us to drop this directory from the black exclusion list. # skip-blame blackening Differential Revision: https://phab.mercurial-scm.org/D7937
Tue, 21 Jan 2020 15:45:06 -0800 tests: move non-collapse test out of test-rebase-collapse
Martin von Zweigbergk <martinvonz@google.com> [Tue, 21 Jan 2020 15:45:06 -0800] rev 44146
tests: move non-collapse test out of test-rebase-collapse The test case was added in 76630fbbf4fa (test-rebase-collapse: Add test for rebase regression introduced in 12309c09d19a, 2012-01-23). I think `hg rebase --collapse` was involved in either the regression or in the fix that caused the regression, but the test that was added doesn't use `--collapse`, so it doesn't seem to belong in test-rebase-collapse.t. The test case is about copies, so I moved it to test-rebase-rename.t. Differential Revision: https://phab.mercurial-scm.org/D7968
Fri, 22 Nov 2019 20:27:09 -0800 debugcommands: add Python implementation to debuginstall
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 22 Nov 2019 20:27:09 -0800] rev 44145
debugcommands: add Python implementation to debuginstall This seems like a useful detail to print. Differential Revision: https://phab.mercurial-scm.org/D7979
Fri, 22 Nov 2019 20:12:10 -0800 run-tests: remove --py3-warnings
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 22 Nov 2019 20:12:10 -0800] rev 44144
run-tests: remove --py3-warnings This Python 2 only mode was to help Python 2 alert when doing things not supported on Python 3. Now that we have test coverage with Python 3, I don't think we need it. Differential Revision: https://phab.mercurial-scm.org/D7978
Wed, 22 Jan 2020 16:37:05 +0100 rust-node: binary Node ID and conversion utilities
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:37:05 +0100] rev 44143
rust-node: binary Node ID and conversion utilities The choice of type makes sure that a `Node` has the exact wanted size. We'll use a different type for prefixes. Added dependency: hexadecimal conversion relies on the `hex` crate. The fact that sooner or later Mercurial is going to need to change its hash sizes has been taken strongly in consideration: - the hash length is a constant, but that is not directly exposed to callers. Changing the value of that constant is the only thing to do to change the hash length (even in unit tests) - the code could be adapted to support several sizes of hashes, if that turned out to be useful. To that effect, only the size of a given `Node` is exposed in the public API. - callers not involved in initial computation, I/O and FFI are able to operate without a priori assumptions on the hash size. The traits `FromHex` and `ToHex` have not been directly implemented, so that the doc-comments explaining these restrictions would stay really visible in `cargo doc` Differential Revision: https://phab.mercurial-scm.org/D7788
Wed, 22 Jan 2020 16:23:29 +0100 rust-nodemap: building blocks for nodetree structures
Georges Racinet <georges.racinet@octobus.net> [Wed, 22 Jan 2020 16:23:29 +0100] rev 44142
rust-nodemap: building blocks for nodetree structures This is similar to `nodetreenode` in `revlog.c`. We give it a higher level feeling for ease of handling in Rust context and provide tools for tests and debugging. The encoding choice is dictated by our ultimate goal in this series, that is to make an append-only persistent version of `nodetree`: the 0th Block must be adressed from other Blocks. Differential Revision: https://phab.mercurial-scm.org/D7787
Tue, 21 Jan 2020 10:13:08 -0500 lfs: move the initialization of the upload request into the try block
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 10:13:08 -0500] rev 44141
lfs: move the initialization of the upload request into the try block This (almost) guarantees that the file is closed in the case of an exception. The one hole is if the `seek(SEEK_END)`/`tell()`/`seek(0)` sequence fails. But that's going to go away when subclassing `httpconnection.httpsendfile` to fix the worker problem, so I'm not going to worry too much. (And that class appears to have the same problem.) Differential Revision: https://phab.mercurial-scm.org/D7959
Tue, 21 Jan 2020 09:55:35 -0500 lfs: drop an unnecessary r'' prefix
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 09:55:35 -0500] rev 44140
lfs: drop an unnecessary r'' prefix No longer necessary since the source transformer was removed. # skip-blame for changing string prefixes Differential Revision: https://phab.mercurial-scm.org/D7958
Tue, 21 Jan 2020 09:51:39 -0500 lfs: explicitly close the file handle for the blob being uploaded
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 09:51:39 -0500] rev 44139
lfs: explicitly close the file handle for the blob being uploaded The previous code relied on reading the blob fully to close it. The obvious problem is if an error occurs before that point. But there is also a problem when using workers where the data may need to be re-read, which can't happen once it is closed. This eliminates the surprising behavior before attempting to fix the worker problem. Differential Revision: https://phab.mercurial-scm.org/D7957
Tue, 21 Jan 2020 09:40:40 -0500 lfs: drop the unused progressbar code in the `filewithprogress` class
Matt Harbison <matt_harbison@yahoo.com> [Tue, 21 Jan 2020 09:40:40 -0500] rev 44138
lfs: drop the unused progressbar code in the `filewithprogress` class This has been unused since f98fac24b757, which added worker based transfers for concurrency, shifting the progressbar maintenance to the single thread waiting on the worker to complete. Since the name no longer fits, rename the class. Differential Revision: https://phab.mercurial-scm.org/D7956
Tue, 14 Jan 2020 16:58:07 +0100 rust-filepatterns: remove bridge code for filepatterns-related functions
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 16:58:07 +0100] rev 44137
rust-filepatterns: remove bridge code for filepatterns-related functions These functions will be used internally by `hg-core` without needed to be exposed to Python. Differential Revision: https://phab.mercurial-scm.org/D7868
Tue, 14 Jan 2020 18:03:28 +0100 rust-utils: add Rust implementation of Python's "os.path.splitdrive"
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 18:03:28 +0100] rev 44136
rust-utils: add Rust implementation of Python's "os.path.splitdrive" I also wrote the NT version although I didn't mean to at first, so I thought I would keep it, so that any further effort to get the Rust code working on Windows is a little easier. Differential Revision: https://phab.mercurial-scm.org/D7864
Tue, 21 Jan 2020 17:15:34 -0800 crecord: fix a concatenation of bytes and str on py3 stable
Kyle Lippincott <spectral@google.com> [Tue, 21 Jan 2020 17:15:34 -0800] rev 44135
crecord: fix a concatenation of bytes and str on py3 Differential Revision: https://phab.mercurial-scm.org/D7970
Wed, 22 Jan 2020 14:11:11 -0500 recover: fix typos stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Wed, 22 Jan 2020 14:11:11 -0500] rev 44134
recover: fix typos Differential Revision: https://phab.mercurial-scm.org/D7971
Tue, 21 Jan 2020 10:27:39 -0800 relnotes: copy "next" to "5.3" and clear "next" stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 21 Jan 2020 10:27:39 -0800] rev 44133
relnotes: copy "next" to "5.3" and clear "next" This is the same thing as we've done for the last two releases. Differential Revision: https://phab.mercurial-scm.org/D7955
Tue, 21 Jan 2020 12:10:35 -0800 cext: change two more vars to Py_ssize_t in manifest.c stable
Kyle Lippincott <spectral@google.com> [Tue, 21 Jan 2020 12:10:35 -0800] rev 44132
cext: change two more vars to Py_ssize_t in manifest.c D7913 fixed a compiler warning with a signedness conflict in a ternary operator by changing the types of some variables to be Py_ssize_t instead of size_t or int. That commit missed these two cases since they aren't warned about (at least on my compiler). Both of these variables are produced by operations on variables that are themselves Py_ssize_t now/already, so they should keep the same type. Differential Revision: https://phab.mercurial-scm.org/D7964
Tue, 21 Jan 2020 13:16:30 -0500 Added signature for changeset 84a0102c05c7 stable
Augie Fackler <raf@durin42.com> [Tue, 21 Jan 2020 13:16:30 -0500] rev 44131
Added signature for changeset 84a0102c05c7
Tue, 21 Jan 2020 13:16:29 -0500 Added tag 5.3rc0 for changeset 84a0102c05c7 stable
Augie Fackler <raf@durin42.com> [Tue, 21 Jan 2020 13:16:29 -0500] rev 44130
Added tag 5.3rc0 for changeset 84a0102c05c7
Tue, 21 Jan 2020 13:14:51 -0500 merge to stable for 5.3 release freeze stable 5.3rc0
Augie Fackler <augie@google.com> [Tue, 21 Jan 2020 13:14:51 -0500] rev 44129
merge to stable for 5.3 release freeze
Fri, 17 Jan 2020 16:56:49 -0500 phabricator: use .arcconfig for `phabricator.url` if not set locally
Matt Harbison <matt_harbison@yahoo.com> [Fri, 17 Jan 2020 16:56:49 -0500] rev 44128
phabricator: use .arcconfig for `phabricator.url` if not set locally This setting is also per repo; see the previous commit for details. The existing `conduit_uri` setting is the previous name of `phabricator.uri`[1] and while it could easily be queried before the latter for compatibility, the config in this repo has '/api' appended. That's already done in `callconduit()`, which would clearly end up giving the wrong result. It looks like the path of the URL is now ignored in user configs[2], so add the modern setting without it to this repo's .arcconfig. Sadly, we still need to have contributors configure `auth.hg.phabtoken` (and therefore `auth.hg.prefix` to link it to `phabricator.url`) in order to submit patches, but at least now it's localized to a single section. [1] https://secure.phabricator.com/book/phabricator/article/arcanist_new_project/ [2] https://github.com/phacility/arcanist/blob/cc850163f30c4697e925df0d6212469679600a2c/scripts/arcanist.php#L271 Differential Revision: https://phab.mercurial-scm.org/D7935
Fri, 17 Jan 2020 14:21:40 -0500 phabricator: use .arcconfig for the callsign if not set locally (issue6243)
Matt Harbison <matt_harbison@yahoo.com> [Fri, 17 Jan 2020 14:21:40 -0500] rev 44127
phabricator: use .arcconfig for the callsign if not set locally (issue6243) This makes things easier for people working with more than one repository because this file can be committed to each repository. The bug report asks to read <repo>/.arcrc, but AFAICT, that file lives in ~/ and holds the credentials. And we already track an .arcconfig file. Any callsign set globally is still used if that is all that is present, but .arcconfig will override it if available. The idea behind letting the local hgrc override .arcconfig is that the developer may need to do testing against another server, and not dirty the working directory. Originally I was going to just try to read the callsign in `getrepophid()` if it wasn't present in the hg config. That works fine, but I think it also makes sense to read the URL from this file too. That would have worked less well because `readurltoken()` doesn't have access to the repo object to know where to find the file. Supplimenting the config mechanism is less magical because it reports the source and value of the properties used, and it doesn't need to read the file twice. Invalid hgrc files generally cause the program to abort. I only flagged it as a warning here because it's not our config file, not crucial to the whole program operating, and really shouldn't be corrupt in the typical case where it is checked into the repo. Differential Revision: https://phab.mercurial-scm.org/D7934
Fri, 17 Jan 2020 13:29:47 -0500 config: add a function to insert non-file based, but overridable settings
Matt Harbison <matt_harbison@yahoo.com> [Fri, 17 Jan 2020 13:29:47 -0500] rev 44126
config: add a function to insert non-file based, but overridable settings This will be used in the next patch. Until relatively recently (473510bf0575), there was no official way for extensions to inject per-repo config data, so it probably makes sense that `ui.setconfig()` items are sticky, and not affected by loading more config files. But that makes it cumbersome if the extension wants to allow the data it might add to be overridden by any data in the local hgrc file. The only thing I could get to work was to load the local hgrc first, and then check if the source for the config item that should be overridden was *not* the local hgrc file name. But that's brittle because in addition to the file name, the source contains the line number, there are the usual '\' vs '/' platform differences, etc. Differential Revision: https://phab.mercurial-scm.org/D7933
Thu, 16 Jan 2020 19:48:01 -0500 tests: restore phabricator tests and regenerate the recordings
Matt Harbison <matt_harbison@yahoo.com> [Thu, 16 Jan 2020 19:48:01 -0500] rev 44125
tests: restore phabricator tests and regenerate the recordings These contain the new API chatter. Most of the changes are because some new commits were created, but they're pretty obviously equivalent. I have no idea why the last recording contains real data, whereas it previously looked fake. Differential Revision: https://phab.mercurial-scm.org/D7920
Tue, 07 Jan 2020 11:24:05 +0100 hgrc: introduce HGRCSKIPREPO to skip reading the repository's hgrc
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 07 Jan 2020 11:24:05 +0100] rev 44124
hgrc: introduce HGRCSKIPREPO to skip reading the repository's hgrc We had a way to change the behavior regarding reading the global and user config, but we had nothing regarding the repository hgrc itself. This option is useful in situation where scripts need to be able to work around strange configuration set by the user in his repository. (and were HGPLAIN is not enough). Differential Revision: https://phab.mercurial-scm.org/D7807
Sat, 18 Jan 2020 10:37:14 -0800 debugcommands: move away from line buffered output on binary stream
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 18 Jan 2020 10:37:14 -0800] rev 44123
debugcommands: move away from line buffered output on binary stream Line buffering on binary file objects is apparently undefined behavior in Python and emits a RuntimeWarning on Python 3.8. See https://bugs.python.org/issue32236. This commit changes the I/O logging file descriptor from line buffered to unbuffered to work around this. I'm no fan of unbuffered I/O for performance reasons. But I don't think it is an issue here given the nature of the code. With this change, test-ssh-proto.t now passes on Python 3.8. Differential Revision: https://phab.mercurial-scm.org/D7948
Sat, 18 Jan 2020 10:43:52 -0800 py3: conditionalize test-lfs-serve-access.t for Python 3.8
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 18 Jan 2020 10:43:52 -0800] rev 44122
py3: conditionalize test-lfs-serve-access.t for Python 3.8 This is another case where Python 3.8's traceback printing varies subtly from older Python versions. Again, I'm not sure why. But this is apparently the new behavior. With this change, test-lfs-serve-access.t now passes on Python 3.8! Differential Revision: https://phab.mercurial-scm.org/D7947
Sat, 18 Jan 2020 10:27:03 -0800 py3: add extra traceback line present on Python 3.8
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 18 Jan 2020 10:27:03 -0800] rev 44121
py3: add extra traceback line present on Python 3.8 I'm not sure why Python 3.8 is outputting this line. It appears to be a change in behavior of formatting tracebacks on Python 3.8. So let's add it to expected output. With this change, test-hook.t now passes on Python 3.8. Differential Revision: https://phab.mercurial-scm.org/D7946
Sat, 18 Jan 2020 10:12:41 -0800 py3: conditionalize test-flagprocessor.t on Python 3.8
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 18 Jan 2020 10:12:41 -0800] rev 44120
py3: conditionalize test-flagprocessor.t on Python 3.8 For reasons I don't understand, Python 3.8 is outputting a different lint in the traceback than prior Pythons. The lines in question are: flagutil.addflagprocessor( REVIDX_NOOP, (noopdonothingread, noopdonothing, validatehash,) ) Python <3.8 prints the 2nd line but 3.8 the first line. Perhaps Python changed its traceback logic to always print the first line of a multiple line expression? Whatever the case, with this change, the test now passes on Python 3.8. Differential Revision: https://phab.mercurial-scm.org/D7945
Sat, 18 Jan 2020 10:21:45 -0800 tests: conditionalize test-hightlight.t on pygments version
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 18 Jan 2020 10:21:45 -0800] rev 44119
tests: conditionalize test-hightlight.t on pygments version Output changed slightly in pygments 2.5. I thought it was easier to copy the line and add a version check than to add a regular expression because the line has some special characters. I also like tests explicitly calling out where they vary. Differential Revision: https://phab.mercurial-scm.org/D7943
Mon, 20 Jan 2020 23:51:25 -0800 hgdemandimport: apply lazy module loading to sys.meta_path finders
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 20 Jan 2020 23:51:25 -0800] rev 44118
hgdemandimport: apply lazy module loading to sys.meta_path finders Python's `sys.meta_path` finders are the primary objects whose job it is to find a module at import time. When `import` is called, Python iterates objects in this list and calls `o.find_spec(...)` to find a `ModuleSpec` (or None if the module couldn't be found by that finder). If no meta path finder can find a module, import fails. One of the default meta path finders is `PathFinder`. Its job is to import modules from the filesystem and is probably the most important importer. This finder looks at `sys.path` and `sys.path_hooks` to do its job. The `ModuleSpec` returned by `MetaPathImporter.find_spec()` has a `loader` attribute, which defines the concrete module loader to use. `sys.path_hooks` is a hook point for teaching `PathFinder` to instantiate custom loader types. Previously, we injected a custom `sys.path_hook` that told `PathFinder` to wrap the default loaders with a loader that creates a module object that is lazy. This approach worked. But its main limitation was that it only applied to the `PathFinder` meta path importer. There are other meta path importers that are registered. And in the case of PyOxidizer loading modules from memory, `PathFinder` doesn't come into play since PyOxidizer's own meta path importer was handling all imports. This commit changes our approach to lazy module loading by proxying all meta path importers. Specifically, we overload the `find_spec()` method to swap in a wrapped loader on the `ModuleSpec` before it is returned. The end result of this is all meta path importers should be lazy. As much as I would have loved to utilize .__class__ manipulation to achieve this, some meta path importers are implemented in C/Rust in such a way that they cannot be monkeypatched. This is why we use __getattribute__ to define a proxy. Also, this change could theoretically open us up to regressions in meta path importers whose loader is creating module objects which can't be monkeypatched. But I'm not aware of any of these in the wild. So I think we'll be safe. According to hyperfine, this change yields a decent startup time win of 5-6ms: ``` Benchmark #1: ~/.pyenv/versions/3.6.10/bin/python ./hg version Time (mean ± σ): 86.8 ms ± 0.5 ms [User: 78.0 ms, System: 8.7 ms] Range (min … max): 86.0 ms … 89.1 ms 50 runs Time (mean ± σ): 81.1 ms ± 2.7 ms [User: 74.5 ms, System: 6.5 ms] Range (min … max): 77.8 ms … 90.5 ms 50 runs Benchmark #2: ~/.pyenv/versions/3.7.6/bin/python ./hg version Time (mean ± σ): 78.9 ms ± 0.6 ms [User: 70.2 ms, System: 8.7 ms] Range (min … max): 78.1 ms … 81.2 ms 50 runs Time (mean ± σ): 73.4 ms ± 0.6 ms [User: 65.3 ms, System: 8.0 ms] Range (min … max): 72.4 ms … 75.7 ms 50 runs Benchmark #3: ~/.pyenv/versions/3.8.1/bin/python ./hg version Time (mean ± σ): 78.1 ms ± 0.6 ms [User: 70.2 ms, System: 7.9 ms] Range (min … max): 77.4 ms … 80.9 ms 50 runs Time (mean ± σ): 72.1 ms ± 0.4 ms [User: 64.4 ms, System: 7.6 ms] Range (min … max): 71.4 ms … 74.1 ms 50 runs ``` Differential Revision: https://phab.mercurial-scm.org/D7954
Mon, 20 Jan 2020 23:42:19 -0800 hgdemandimport: disable on Python 3.5
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 20 Jan 2020 23:42:19 -0800] rev 44117
hgdemandimport: disable on Python 3.5 The demand importer functionality isn't working at all on Python 3.5. I'm not sure what's wrong. Since it isn't working, let's disable it completely. ``` $ HGRCPATH= hyperfine -w 1 -r 50 -- "~/.pyenv/versions/3.5.9/bin/python ./hg version" \ "HGDEMANDIMPORT=disable ~/.pyenv/versions/3.5.9/bin/python ./hg version" Benchmark #1: ~/.pyenv/versions/3.5.9/bin/python ./hg version Time (mean ± σ): 163.7 ms ± 2.2 ms [User: 148.5 ms, System: 15.7 ms] Range (min … max): 161.0 ms … 170.2 ms 50 runs Benchmark #2: HGDEMANDIMPORT=disable ~/.pyenv/versions/3.5.9/bin/python ./hg version Time (mean ± σ): 164.3 ms ± 1.4 ms [User: 148.2 ms, System: 16.6 ms] Range (min … max): 161.4 ms … 169.8 ms 50 runs ``` Differential Revision: https://phab.mercurial-scm.org/D7953
Sat, 18 Jan 2020 11:13:01 -0800 py3: suppress unraisable exceptions in test-worker.t
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 18 Jan 2020 11:13:01 -0800] rev 44116
py3: suppress unraisable exceptions in test-worker.t Python 3.8 calls sys.unraisablehook when an unraisable exception is encountered. The default behavior is to print a warning. test-worker.t was triggering this hook due to a race between a newly forked process exiting and that process's _os.register_at_fork handlers running. I was seeing the stdlib's random module in the stack re-seeding itself. Although there could be other after-fork handlers in the mix. This commit defines sys.unraisablehook to effectively no-op. This suppresses the warning and makes test output on Python 3.8 consistent with prior versions. test-worker.t now passes on Python 3.8. Differential Revision: https://phab.mercurial-scm.org/D7949
Mon, 20 Jan 2020 18:28:46 -0500 rust: add a README
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 20 Jan 2020 18:28:46 -0500] rev 44115
rust: add a README In particular to explain how to build any of the rust. It's neither obvious, nor easy to find out, nor easy to determine if you did it right without some documentation. Differential Revision: https://phab.mercurial-scm.org/D7952
Mon, 20 Jan 2020 17:44:03 -0500 rust: move hgcli's README out of the way
Valentin Gatien-Baron <valentin.gatienbaron@gmail.com> [Mon, 20 Jan 2020 17:44:03 -0500] rev 44114
rust: move hgcli's README out of the way My understanding is that it's not meant to be used in the current form. Differential Revision: https://phab.mercurial-scm.org/D7951
Sat, 18 Jan 2020 01:54:17 -0500 verify: avoid spurious integrity warnings in verbose mode (issue6172)
Matt Harbison <matt_harbison@yahoo.com> [Sat, 18 Jan 2020 01:54:17 -0500] rev 44113
verify: avoid spurious integrity warnings in verbose mode (issue6172) The issue seems to revolve around renames in filtered commits, and only occurred in verbose mode. The problem occurs in the `# check renames` stage, around line 577. Without using the unfiltered repo, this test would have printed: $ hg verify -v repository uses revlog format 1 checking changesets checking manifests crosschecking files in changesets and manifests checking files foo@25: checking rename of 71ec0570c325: filtered revision '25' foobar@26: checking rename of 1b549296015b: filtered revision '26' checked 28 changesets with 16 changes to 11 files 2 integrity errors encountered! (first damaged changeset appears to be 25) [1] Differential Revision: https://phab.mercurial-scm.org/D7950
Fri, 17 Jan 2020 22:31:47 -0800 py3: glob over exception in test-check-py3-compat.t
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 17 Jan 2020 22:31:47 -0800] rev 44112
py3: glob over exception in test-check-py3-compat.t Python 3.6+ raise ModuleNotFoundError and older versions raise ImportError. Glob over the exception differences. For whatever reason, we were already doing this for one failure. But not all occurrences of ModuleNotFoundError were changed. Who knows. This test should now pass on all Python versions (although I didn't check Windows). Differential Revision: https://phab.mercurial-scm.org/D7939
Fri, 17 Jan 2020 22:24:27 -0800 py3: string normalization and I/O tweaks in test-lfs.t
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 17 Jan 2020 22:24:27 -0800] rev 44111
py3: string normalization and I/O tweaks in test-lfs.t The print was inserting b'' on Python 3. In addition, since we weren't writing to the ui instance (which isn't readily available in this function), output order could get mixed up. We add some pycompat casts and a stdout flush to make the test happy on all Python versions. Differential Revision: https://phab.mercurial-scm.org/D7938
Fri, 17 Jan 2020 21:27:53 -0500 help: minor copy editing to the `config.format` section
Matt Harbison <matt_harbison@yahoo.com> [Fri, 17 Jan 2020 21:27:53 -0500] rev 44110
help: minor copy editing to the `config.format` section Differential Revision: https://phab.mercurial-scm.org/D7936
Thu, 21 Nov 2019 17:27:44 +0100 changectx: mark parent of changesets as non filtered
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Nov 2019 17:27:44 +0100] rev 44109
changectx: mark parent of changesets as non filtered If a node is not filtered, its parents cannot be filtered. Differential Revision: https://phab.mercurial-scm.org/D7502
Thu, 21 Nov 2019 23:46:51 +0100 changectx: use unfiltered changelog to walk ancestors in annotate
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Nov 2019 23:46:51 +0100] rev 44108
changectx: use unfiltered changelog to walk ancestors in annotate Since we are only walking ancestors, it is safe to use an unfiltered repository. (Because if the original rev is not filtered, none of its ancestors will be). Differential Revision: https://phab.mercurial-scm.org/D7501
Thu, 21 Nov 2019 23:25:08 +0100 localrepo: also fast past the parents of working copies parents
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 21 Nov 2019 23:25:08 +0100] rev 44107
localrepo: also fast past the parents of working copies parents There are descent odds that they will be needed too. So we also cache and fastpath them. Differential Revision: https://phab.mercurial-scm.org/D7498
Sun, 17 Nov 2019 14:54:41 +0100 localrepo: recognize trivial request for '.'
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 17 Nov 2019 14:54:41 +0100] rev 44106
localrepo: recognize trivial request for '.' Same logic as for `null`, this is a command request and skipping the revset logic can avoid triggering the changelog filtering logic. Differential Revision: https://phab.mercurial-scm.org/D7495
Sun, 17 Nov 2019 14:47:29 +0100 localrepo: fastpath access to "."
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 17 Nov 2019 14:47:29 +0100] rev 44105
localrepo: fastpath access to "." "." is just an alias for `p1(wdir())`, let us handle it that way. Differential Revision: https://phab.mercurial-scm.org/D7494
Sun, 17 Nov 2019 14:39:28 +0100 localrepo: also fastpath access to working copy parents when possible
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 17 Nov 2019 14:39:28 +0100] rev 44104
localrepo: also fastpath access to working copy parents when possible If the filter level guarantee that the working copy parents will be visible, we allow fast path access to them. With this change multiple commands can now run without triggering filtering. After using the quick access mechanism introduced, the whole series results in pretty good performance gain: ``` All benchmarks: before after ratio [8e095512] [36b2f659] - 711±0.8ms 60.7±0.2ms 0.09 simple_command.read.diff.empty.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 1) [citrea/virtualenv-py2.7-pyyaml-HGMODULEPOLICYc-HGWITHRUSTEXTcpython] - 712±0.8ms 61.6±0.2ms 0.09 simple_command.read.diff.empty.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 1) [citrea/virtualenv-py2.7-pyyaml-HGMODULEPOLICYrust+c-HGWITHRUSTEXTcpython] - 690±1ms 93.5±0.3ms 0.14 simple_command.read.diff.empty.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 1) [citrea/virtualenv-py3.7-pyyaml-HGMODULEPOLICYc-HGWITHRUSTEXTcpython] - 688±1ms 93.8±0.3ms 0.14 simple_command.read.diff.empty.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 1) [citrea/virtualenv-py3.7-pyyaml-HGMODULEPOLICYrust+c-HGWITHRUSTEXTcpython] - 714±1ms 60.7±0.8ms 0.09 simple_command.read.diff.empty.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 2) [citrea/virtualenv-py2.7-pyyaml-HGMODULEPOLICYc-HGWITHRUSTEXTcpython] - 713±1ms 60.9±0.3ms 0.09 simple_command.read.diff.empty.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 2) [citrea/virtualenv-py2.7-pyyaml-HGMODULEPOLICYrust+c-HGWITHRUSTEXTcpython] - 689±1ms 93.7±0.2ms 0.14 simple_command.read.diff.empty.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 2) [citrea/virtualenv-py3.7-pyyaml-HGMODULEPOLICYc-HGWITHRUSTEXTcpython] - 687±2ms 92.8±0.2ms 0.14 simple_command.read.diff.empty.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 2) [citrea/virtualenv-py3.7-pyyaml-HGMODULEPOLICYrust+c-HGWITHRUSTEXTcpython] - 799±2ms 98.1±0.6ms 0.12 simple_command.read.export.bare.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True) [citrea/virtualenv-py2.7-pyyaml-HGMODULEPOLICYc-HGWITHRUSTEXTcpython] - 800±0.8ms 100.0±0.4ms 0.12 simple_command.read.export.bare.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True) [citrea/virtualenv-py2.7-pyyaml-HGMODULEPOLICYrust+c-HGWITHRUSTEXTcpython] - 711±0.9ms 111±0.2ms 0.16 simple_command.read.export.bare.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True) [citrea/virtualenv-py3.7-pyyaml-HGMODULEPOLICYc-HGWITHRUSTEXTcpython] - 711±1ms 112±0.3ms 0.16 simple_command.read.export.bare.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True) [citrea/virtualenv-py3.7-pyyaml-HGMODULEPOLICYrust+c-HGWITHRUSTEXTcpython] - 760±1ms 59.8±0.1ms 0.08 simple_command.read.status.wc_clean.default.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 1) [citrea/virtualenv-py2.7-pyyaml-HGMODULEPOLICYc-HGWITHRUSTEXTcpython] - 763±2ms 62.2±0.3ms 0.08 simple_command.read.status.wc_clean.default.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 1) [citrea/virtualenv-py2.7-pyyaml-HGMODULEPOLICYrust+c-HGWITHRUSTEXTcpython] - 689±1ms 93.1±0.3ms 0.14 simple_command.read.status.wc_clean.default.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 1) [citrea/virtualenv-py3.7-pyyaml-HGMODULEPOLICYc-HGWITHRUSTEXTcpython] - 688±1ms 94.3±0.3ms 0.14 simple_command.read.status.wc_clean.default.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 1) [citrea/virtualenv-py3.7-pyyaml-HGMODULEPOLICYrust+c-HGWITHRUSTEXTcpython] - 763±1ms 60.1±0.2ms 0.08 simple_command.read.status.wc_clean.default.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 2) [citrea/virtualenv-py2.7-pyyaml-HGMODULEPOLICYc-HGWITHRUSTEXTcpython] - 763±1ms 62.1±0.4ms 0.08 simple_command.read.status.wc_clean.default.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 2) [citrea/virtualenv-py2.7-pyyaml-HGMODULEPOLICYrust+c-HGWITHRUSTEXTcpython] - 689±0.8ms 93.2±0.2ms 0.14 simple_command.read.status.wc_clean.default.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 2) [citrea/virtualenv-py3.7-pyyaml-HGMODULEPOLICYc-HGWITHRUSTEXTcpython] - 687±0.9ms 94.1±0.3ms 0.14 simple_command.read.status.wc_clean.default.time_bench('mercurial-filtered-2019-11-22', 'zstd', 'default', True, True, True, True, True, 2) [citrea/virtualenv-py3.7-pyyaml-HGMODULEPOLICYrust+c-HGWITHRUSTEXTcpython] ``` Differential Revision: https://phab.mercurial-scm.org/D7492
Thu, 16 Jan 2020 08:41:38 -0800 examples: refer to nightly rustfmt in Windows-compatible way
Martin von Zweigbergk <martinvonz@google.com> [Thu, 16 Jan 2020 08:41:38 -0800] rev 44103
examples: refer to nightly rustfmt in Windows-compatible way Thanks to Jun Wu for the tip. I found that the new form also gave better error messages when the nightly rustfmt wasn't installed (it told me which command to run instead of just saying "error: not a file: <some path>"). Differential Revision: https://phab.mercurial-scm.org/D7911
Thu, 26 Dec 2019 19:05:55 +0100 convert: refactor authormap into separate function for outside use
Joerg Sonnenberger <joerg@bec.de> [Thu, 26 Dec 2019 19:05:55 +0100] rev 44102
convert: refactor authormap into separate function for outside use Differential Revision: https://phab.mercurial-scm.org/D7732
Tue, 14 Jan 2020 17:57:15 +0900 remotefilelog: fix opening validatecachelog in text mode
Inada Naoki <songofacandy@gmail.com> [Tue, 14 Jan 2020 17:57:15 +0900] rev 44101
remotefilelog: fix opening validatecachelog in text mode
Thu, 16 Jan 2020 12:27:15 -0800 cext: fix compiler warning about sign changing
Kyle Lippincott <spectral@google.com> [Thu, 16 Jan 2020 12:27:15 -0800] rev 44100
cext: fix compiler warning about sign changing line.len is a Py_ssize_t, and we're casing to size_t (unsigned). On my compiler, this causes a warning to be emitted: ``` mercurial/cext/manifest.c: In function 'pathlen': mercurial/cext/manifest.c:48:44: warning: operand of ?: changes signedness from 'Py_ssize_t' {aka 'long int'} to 'long unsigned int' due to unsignedness of other operand [-Wsign-compare] return (end) ? (size_t)(end - l->start) : l->len; ^~~~~~ ``` Differential Revision: https://phab.mercurial-scm.org/D7913
Wed, 15 Jan 2020 23:34:04 -0500 sha1dc: avoid including the nonexistent stdint.h with Visual Studio 2008
Matt Harbison <matt_harbison@yahoo.com> [Wed, 15 Jan 2020 23:34:04 -0500] rev 44099
sha1dc: avoid including the nonexistent stdint.h with Visual Studio 2008 Differential Revision: https://phab.mercurial-scm.org/D7903
Thu, 16 Jan 2020 12:17:03 -0800 py3: fix curses chunkselector fallback (when diffs are too large) on py3
Kyle Lippincott <spectral@google.com> [Thu, 16 Jan 2020 12:17:03 -0800] rev 44098
py3: fix curses chunkselector fallback (when diffs are too large) on py3 Previously we showed the message using Exception.message, which is removed in py3. Since crecordmod.fallbackerror inherits from error.Abort, we can just use `b'%s' % exception` to print the message. This does not print the hint, but that's fine - we don't set one. We inherit from error.Abort so that if a codepath doesn't handle fallback specially, it exits to the terminal with a sane message instead of an unknown exception error. Differential Revision: https://phab.mercurial-scm.org/D7912
Wed, 15 Jan 2020 15:47:03 +0100 transaction: allow finalizer to add finalizer
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Jan 2020 15:47:03 +0100] rev 44097
transaction: allow finalizer to add finalizer It will make some code (persistent nodemap related) simpler to write, because higher level code can blindly queue finalization without thinking too hard about the context. Differential Revision: https://phab.mercurial-scm.org/D7833
Sat, 28 Dec 2019 12:25:16 -0500 tests: stabilize test-subrepo-svn.t on Windows
Matt Harbison <matt_harbison@yahoo.com> [Sat, 28 Dec 2019 12:25:16 -0500] rev 44096
tests: stabilize test-subrepo-svn.t on Windows This partially reverts 991e4404e910, because the URL form of `C:\...` gets escaped to `C%3A/...`, which breaks the substitution of $TESTTMP. The forget command on 'notafile*' errored out with: notafile*: The filename, directory name, or volume label syntax is incorrect which I think is because '*' isn't a legal character in a file name (though I can't trigger this directly from MSYS or cmd.exe for some reason). Differential Revision: https://phab.mercurial-scm.org/D7816
Mon, 13 Jan 2020 11:18:29 -0800 rebase: fix bug where `--collapse` would apply diff on missing file
Martin von Zweigbergk <martinvonz@google.com> [Mon, 13 Jan 2020 11:18:29 -0800] rev 44095
rebase: fix bug where `--collapse` would apply diff on missing file Even though the file was missing, the rebase would succeed. Differential Revision: https://phab.mercurial-scm.org/D7897
Mon, 13 Jan 2020 11:11:20 -0800 rebase: extract a variable for a repeated `repo[p1]`
Martin von Zweigbergk <martinvonz@google.com> [Mon, 13 Jan 2020 11:11:20 -0800] rev 44094
rebase: extract a variable for a repeated `repo[p1]` I'll add another use site in the next patch. Differential Revision: https://phab.mercurial-scm.org/D7896
Sun, 29 Dec 2019 17:53:48 -0800 graftcopies: document why the function is useful at all
Martin von Zweigbergk <martinvonz@google.com> [Sun, 29 Dec 2019 17:53:48 -0800] rev 44093
graftcopies: document why the function is useful at all Despite having spent a significant amount on time on the copy-tracing code, I thought `graftcopies()` (formerly known as `duplicatecopies()`) was needed to duplicate copies after calling `merge.update()` to do a merge (as `merge.graft()` does), but it's actually usually not needed; `merge.update()` takes care of most copies. This patch documents what the function is for. Differential Revision: https://phab.mercurial-scm.org/D7861
Fri, 27 Dec 2019 13:47:59 -0800 graftcopies: remove `skip` and `repo` arguments
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Dec 2019 13:47:59 -0800] rev 44092
graftcopies: remove `skip` and `repo` arguments The `skip` argument was added in 2ba6c9b4e0eb (rebase: fix bug that caused transitive copy records to disappear (issue4192), 2014-06-07) in order to fix https://bz.mercurial-scm.org/show_bug.cgi?id=4192. I ran tests at that commit without the `skiprev` argument and the only difference I noticed was that `test-rebase-collapse.t` failed differently, in the call that is now on line 501. Without the `skiprev` argument, that call would end up creating another commit because it tried to record an invalid copy. With the previous patch in this series, such invalid copies are no longer recorded, so it seems we don't need the `skip` argument anymore. I also removed the `repo` argument since that also becomes unused with the removal of the `skip` argument. Differential Revision: https://phab.mercurial-scm.org/D7860
Fri, 27 Dec 2019 15:14:19 -0800 graftcopies: use _filter() for filtering out invalid copies
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Dec 2019 15:14:19 -0800] rev 44091
graftcopies: use _filter() for filtering out invalid copies `graftcopies()` (formerly called `duplicatecopies()`) checked that the copy destination existed in the working copy, but it didn't check that copy source existed in the parent of the working copy. In `test-graft.t` we can see that as warnings about not finding ancestors of the copied files, and also empty commits getting created. This patch uses the existing `_filter()` function for filtering out invalid copies. In addition to the aforementioned types, that also includes copies where source and destination is the same. Differential Revision: https://phab.mercurial-scm.org/D7859
Mon, 06 Jan 2020 15:24:36 -0800 copies: replace duplicatecopies() by function that takes contexts
Martin von Zweigbergk <martinvonz@google.com> [Mon, 06 Jan 2020 15:24:36 -0800] rev 44090
copies: replace duplicatecopies() by function that takes contexts The callers mostly have context objects, so let's avoid looking up the same context objects inside `duplicatecopies()`. I also renamed the function to `graftcopies()` since I think that better matches its purpose. I did it in the same commit so it's easier for extensions to switch between the functions. Differential Revision: https://phab.mercurial-scm.org/D7858
Fri, 27 Dec 2019 13:03:40 -0800 graft: extract repo[None] to a variable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Dec 2019 13:03:40 -0800] rev 44089
graft: extract repo[None] to a variable I plan to allow the caller pass in an overlayworkingctx, so this prepares for that. Differential Revision: https://phab.mercurial-scm.org/D7857
Thu, 16 Jan 2020 00:30:08 +0800 rust-core: fix typo in comment
Aay Jay Chan <aayjaychan@itopia.com.hk> [Thu, 16 Jan 2020 00:30:08 +0800] rev 44088
rust-core: fix typo in comment Differential Revision: https://phab.mercurial-scm.org/D7895
Tue, 14 Jan 2020 18:59:49 -0800 sha1dc: use buffer protocol when parsing arguments
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 14 Jan 2020 18:59:49 -0800] rev 44087
sha1dc: use buffer protocol when parsing arguments Without this, functions won't accept bytearray, memoryview, or other types that can be exposed as bytes to the C API. The most resilient way to obtain a bytes-like object from the C API is using the Py_buffer interface. This commit converts use of s#/y# to s*/y* and uses Py_buffer for accessing the underlying bytes array. I checked how hashlib is implemented in CPython and the the implementation agrees with its use of the Py_buffer interface as well as using BufferError in cases of bad buffer types. Sadly, there's no good way to test for ndim > 1 without writing our own C-backed Python type. Differential Revision: https://phab.mercurial-scm.org/D7879
Tue, 14 Jan 2020 20:05:37 -0500 lfs: avoid quadratic performance in processing server responses
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Jan 2020 20:05:37 -0500] rev 44086
lfs: avoid quadratic performance in processing server responses This is also adapted from the Facebook repo[1]. Unlike there, we were already reading the download stream in chunks and immediately writing it to disk, so we basically avoided the problem on download. There shouldn't be a lot of data to read on upload, but it's better to get rid of this pattern. [1] https://github.com/facebookexperimental/eden/commit/82df66ffe97e21f3ee73dfec093c87500fc1f6a7 Differential Revision: https://phab.mercurial-scm.org/D7882
Tue, 14 Jan 2020 19:42:24 -0500 lfs: check content length after downloading content
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Jan 2020 19:42:24 -0500] rev 44085
lfs: check content length after downloading content Adapted from the Facebook repo[1]. The intent is to distinguish between the connection dying and getting served a corrupt blob. The original message: HTTP makes no provision to tell your client that you failed halfway through producing your response and won't have the answer they're looking for. So, if a LFS server fails while producing a response, then we'll report an OID mismatch. We can do a little better and disambiguate between "the server sent us the wrong blob" (very scary) and "the server crashed" (merely annoying) by looking at the content length of the response we got back. If it's not what was advertised, we can reasonably safely assume the server crashed. [1] https://github.com/facebookexperimental/eden/commit/2a4a6fab4e882ed89b948bfc1e7d56d7c3c99dd2 Differential Revision: https://phab.mercurial-scm.org/D7881
Tue, 14 Jan 2020 18:02:20 -0500 lfs: rename a variable to clarify its use
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Jan 2020 18:02:20 -0500] rev 44084
lfs: rename a variable to clarify its use This is the response object, not a request. Differential Revision: https://phab.mercurial-scm.org/D7880
Tue, 14 Jan 2020 17:53:43 -0800 sha1dc: use proper string functions on Python 2/3
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 14 Jan 2020 17:53:43 -0800] rev 44083
sha1dc: use proper string functions on Python 2/3 PyString_FromStringAndSize doesn't exist on Python 3: we need to use PyUnicode_FromStringAndSize. The extension now compiles without warnings on Python 2 and 3. Differential Revision: https://phab.mercurial-scm.org/D7878
Tue, 14 Jan 2020 17:39:12 -0800 sha1dc: declare all variables at begininng of block
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 14 Jan 2020 17:39:12 -0800] rev 44082
sha1dc: declare all variables at begininng of block This is required to appease ancient C language standards, which msvc 2008 still requires for Python 2.7 on Windows. Differential Revision: https://phab.mercurial-scm.org/D7877
Tue, 14 Jan 2020 17:37:04 -0800 sha1dc: manually define integer types on msvc 2008
Gregory Szorc <gregory.szorc@gmail.com> [Tue, 14 Jan 2020 17:37:04 -0800] rev 44081
sha1dc: manually define integer types on msvc 2008 Python 2.7 on Windows builds with MSVC 2008, which doesn't include stdint.h. So we need to check for the compiler version and manually define missing types when it is ancient. Differential Revision: https://phab.mercurial-scm.org/D7876
Tue, 14 Jan 2020 14:18:11 -0800 packaging: leverage os.path.relpath() in setup.py
Martin von Zweigbergk <martinvonz@google.com> [Tue, 14 Jan 2020 14:18:11 -0800] rev 44080
packaging: leverage os.path.relpath() in setup.py `os.path.relpath()` has existed since Python 2.6, so we can safely use it. This fixes a bug in the current code when the common prefix is "/" (in which case `uplevel` would be one less than it should). Differential Revision: https://phab.mercurial-scm.org/D7875
Tue, 14 Jan 2020 18:00:05 +0100 rust-utils: add util to find a slice in another slice
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 18:00:05 +0100] rev 44079
rust-utils: add util to find a slice in another slice Differential Revision: https://phab.mercurial-scm.org/D7863
Tue, 14 Jan 2020 16:00:57 +0100 dirstate: move rust fast-path calling code to its own method
Raphaël Gomès <rgomes@octobus.net> [Tue, 14 Jan 2020 16:00:57 +0100] rev 44078
dirstate: move rust fast-path calling code to its own method This logic is about to get bigger, this will make it easier to read and not pollute the main Python logic. Differential Revision: https://phab.mercurial-scm.org/D7862
Tue, 14 Jan 2020 00:52:53 -0500 lfs: add "bytes" as the unit to the upload/download progress bar
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Jan 2020 00:52:53 -0500] rev 44077
lfs: add "bytes" as the unit to the upload/download progress bar Facebook also passes `util.bytecount()` as a pretty formatter here, but our progress bar doesn't support that. Differential Revision: https://phab.mercurial-scm.org/D7872
Tue, 14 Jan 2020 16:37:45 -0500 phabricator: post revisions in ascending topological order (issue6241)
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Jan 2020 16:37:45 -0500] rev 44076
phabricator: post revisions in ascending topological order (issue6241) The parent in phabricator ends up being the last revision posted, so sorting the user input into ascending order should be enough to preserve the proper relationships. Differential Revision: https://phab.mercurial-scm.org/D7874
Tue, 14 Jan 2020 16:29:03 -0500 doc: fix references to `revset.abstractsmartset`
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Jan 2020 16:29:03 -0500] rev 44075
doc: fix references to `revset.abstractsmartset` Differential Revision: https://phab.mercurial-scm.org/D7873
Mon, 13 Jan 2020 20:09:32 -0800 fsmonitor: properly handle str ex.msg
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 13 Jan 2020 20:09:32 -0800] rev 44074
fsmonitor: properly handle str ex.msg ex.msg is always a str, since pywatchman uses str for exception messages. This commit removes a b'' from a string compare to avoid types mismatch and adds a coercion to bytes before stuffing the exception message on our local exception type, which uses bytes for the message elsewhere in this file. Differential Revision: https://phab.mercurial-scm.org/D7855
Mon, 23 Dec 2019 01:12:20 -0500 verify: allow the storage to signal when renames can be tested on `skipread`
Matt Harbison <matt_harbison@yahoo.com> [Mon, 23 Dec 2019 01:12:20 -0500] rev 44073
verify: allow the storage to signal when renames can be tested on `skipread` This applies the new marker in the lfs handler to show it in action, and adds the test mentioned at the beginning of the series to show that fulltext isn't necessary in the LFS case. The existing `skipread` isn't enough, because it is also set if an error occurs reading the revlog data, or the data is censored. It could probably be cleared, but then it technically violates the interface contract. That wouldn't matter for the existing verify algorithm, but it isn't clear how that will change as alternate storage support is added. The flag is probably pretty revlog specific, given the comments in verify.py. But there's already filelog specific stuff in there and I'm not sure what future storage will bring, so I don't want to over-engineer this. Likewise, I'm not sure that we want the verify method for each storage type to completely drive the bus when it comes to detecting renames, so I don't want to go down the rabbithole of having verifyintegrity() return metadata hints at this point. Differential Revision: https://phab.mercurial-scm.org/D7713
Sun, 22 Dec 2019 23:50:19 -0500 lfs: don't skip locally available blobs when verifying
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Dec 2019 23:50:19 -0500] rev 44072
lfs: don't skip locally available blobs when verifying The `skipflags` config was introduced in a2ab9ebcd85b, which specifically calls out downloading and storing all blobs as potentially too expensive. But I don't see any reason to skip blobs that are already available locally. Hashing the blob is the only way to indirectly verify the rawdata content stored in the revlog. (The note in that commit about skipping renamed is still correct, but the reason given about needing fulltext isn't.) Differential Revision: https://phab.mercurial-scm.org/D7712
Fri, 20 Dec 2019 01:11:35 -0500 lfs: add a switch to `hg verify` to ignore the content of blobs
Matt Harbison <matt_harbison@yahoo.com> [Fri, 20 Dec 2019 01:11:35 -0500] rev 44071
lfs: add a switch to `hg verify` to ignore the content of blobs Trying to validate the fulltext of an external revision causes missing blobs to be downloaded and cached. Since the downloads aren't batch prefetched[1] and aren't compressed, this can be expensive both in terms of time and space. I made this a tri-state instead of a simple bool because there's an existing (undocumented) config to handle this, and it would be weird if `hg verify` were to suddenly start ignoring that config but an `hg recover` initiated verify honors it. Since this uses the same config setting, it too will skip rename verification (which requires fulltext, but not for LFS). [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-April/116118.html Differential Revision: https://phab.mercurial-scm.org/D7708
Wed, 08 Jan 2020 14:37:54 -0500 revlog: run rustfmt nightly
Augie Fackler <augie@google.com> [Wed, 08 Jan 2020 14:37:54 -0500] rev 44070
revlog: run rustfmt nightly I'm a little nervous about folding this back (might be nightly rustfmt mismatches?) so I want someone to review this. Differential Revision: https://phab.mercurial-scm.org/D7813
Wed, 08 Jan 2020 14:37:01 -0500 examples: specify rustfmt nightly using a $() construct
Augie Fackler <augie@google.com> [Wed, 08 Jan 2020 14:37:01 -0500] rev 44069
examples: specify rustfmt nightly using a $() construct This is ugly, but it's how we have to configure rustfmt for now as we require nightly rustfmt. Differential Revision: https://phab.mercurial-scm.org/D7812
Sat, 07 Dec 2019 13:13:48 -0800 hg-core: rustfmt path.rs
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 07 Dec 2019 13:13:48 -0800] rev 44068
hg-core: rustfmt path.rs The file as vendored does not conform to our source formatting conventions. Let's reformat it so it does. # skip-blame automated code reformatting Differential Revision: https://phab.mercurial-scm.org/D7580
Sat, 07 Dec 2019 10:26:28 -0800 hg-core: vendor Facebook's path utils module
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 07 Dec 2019 10:26:28 -0800] rev 44067
hg-core: vendor Facebook's path utils module The added file was imported from https://github.com/facebookexperimental/eden/blob/d1d8fb939a39aa331ae7f162c39cbcaa511d474b/eden/scm/lib/util/src/path.rs without modifications. The file is not yet integrated into our project. This will be done in subsequent commits. Differential Revision: https://phab.mercurial-scm.org/D7573
Tue, 14 Jan 2020 12:04:12 +0100 revlog-native: introduced ABI version in capsule
Georges Racinet <georges.racinet@octobus.net> [Tue, 14 Jan 2020 12:04:12 +0100] rev 44066
revlog-native: introduced ABI version in capsule Concerns that an inconsistency could arise between the actual contents of the capsule in revlog.c and the Rust consumer have been raised after the switch to the array of data and function pointers in f384d68d8ea8. It has been suggested that the `version` from parsers.c could be use for this. In this change, we introduce instead a separate ABI version number, which should have the following advantages: - no need to change the consuming Rust code for changes that have nothing to do with the contents of the capsule - the version number in parsers.c is not explicitely flagged as ABI. It's not obvious to me whether an ABI change that would be invisible to Python would warrant an increment The drawback is that developers now have to consider two version numbers. We expect the added cost of the check to be negligible because it occurs at instantiation of `CIndex` only, which in turn is tied to instantiation of Python objects such as `LazyAncestors` and `MixedIndex`. Frequent calls to `Cindex::new` should also probably hit the CPU branch predictor. Differential Revision: https://phab.mercurial-scm.org/D7856
Mon, 13 Jan 2020 19:11:44 -0800 phases: make phasecache._phasesets immutable
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Mon, 13 Jan 2020 19:11:44 -0800] rev 44065
phases: make phasecache._phasesets immutable Previously, some code paths would mutate the cache itself, which could give weird results if multiple revsets got evaluated through that path. Differential Revision: https://phab.mercurial-scm.org/D7854
Mon, 13 Jan 2020 19:06:36 -0800 phases: reduce code duplication in phasecache.getrevset
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Mon, 13 Jan 2020 19:06:36 -0800] rev 44064
phases: reduce code duplication in phasecache.getrevset This is a functional NOP other than reducing some of the duplication in that method. Differential Revision: https://phab.mercurial-scm.org/D7853
Mon, 13 Jan 2020 17:18:03 -0500 scmutil: fix an unbound variable with progressbar debug enabled
Matt Harbison <matt_harbison@yahoo.com> [Mon, 13 Jan 2020 17:18:03 -0500] rev 44063
scmutil: fix an unbound variable with progressbar debug enabled Differential Revision: https://phab.mercurial-scm.org/D7852
Mon, 13 Jan 2020 14:12:31 -0500 hgext: replace references to hashlib.sha1 with hashutil.sha1
Augie Fackler <augie@google.com> [Mon, 13 Jan 2020 14:12:31 -0500] rev 44062
hgext: replace references to hashlib.sha1 with hashutil.sha1 When in a non-pure build of Mercurial, this will provide protections against SHA1 collision attacks. Differential Revision: https://phab.mercurial-scm.org/D7851
Mon, 13 Jan 2020 17:16:54 -0500 sslutil: migrate to hashutil.sha1 instead of hashlib.sha1
Augie Fackler <augie@google.com> [Mon, 13 Jan 2020 17:16:54 -0500] rev 44061
sslutil: migrate to hashutil.sha1 instead of hashlib.sha1 This is a straight-line replacement like the others, but I split it out since it's used in a network context and I'm not sure this is appropriate (we should probably drop support for sha1 fingerprints over TLS) and wanted this to be easily dropped. Differential Revision: https://phab.mercurial-scm.org/D7850
Mon, 13 Jan 2020 17:15:14 -0500 core: migrate uses of hashlib.sha1 to hashutil.sha1
Augie Fackler <augie@google.com> [Mon, 13 Jan 2020 17:15:14 -0500] rev 44060
core: migrate uses of hashlib.sha1 to hashutil.sha1 Differential Revision: https://phab.mercurial-scm.org/D7849
Mon, 13 Jan 2020 17:14:19 -0500 hashutil: new package for hashing-related features
Augie Fackler <augie@google.com> [Mon, 13 Jan 2020 17:14:19 -0500] rev 44059
hashutil: new package for hashing-related features Right now this just tries to use our sha1dc and if it's missing (eg a --pure build) we fall back to hashlib. I imagine in the future we'll want some other things in here for detecting what hasher is in use as we transition off sha1. Differential Revision: https://phab.mercurial-scm.org/D7848
Wed, 08 Jan 2020 15:59:52 -0500 sha1dc: initial implementation of Python extension
Augie Fackler <augie@google.com> [Wed, 08 Jan 2020 15:59:52 -0500] rev 44058
sha1dc: initial implementation of Python extension A future change will use this when available to avoid sha1 collision issues until we can get moved to something else. Differential Revision: https://phab.mercurial-scm.org/D7815
Wed, 08 Jan 2020 15:09:01 -0500 sha1dc: import latest version from github
Augie Fackler <augie@google.com> [Wed, 08 Jan 2020 15:09:01 -0500] rev 44057
sha1dc: import latest version from github After the recent SHA1 news, the attacks are serious enough we should be more proactive. This code will at least allow detection of attacks early. It's already widely deployed in Git. This is git revision 855827c583bc30645ba427885caa40c5b81764d2 of the sha1collisiondetection repo[0], with most of the files omitted. A follow-up change will introduce Python bindings for this code. 0: https://github.com/cr-marcstevens/sha1collisiondetection Differential Revision: https://phab.mercurial-scm.org/D7814
Sat, 11 Jan 2020 05:44:58 +0100 transaction: add a `hasfinalize` method
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 11 Jan 2020 05:44:58 +0100] rev 44056
transaction: add a `hasfinalize` method The method allow code to check if an existing callback exists. It allow them to skip potentially expensive setup for a callback. Differential Revision: https://phab.mercurial-scm.org/D7832
Sat, 11 Jan 2020 04:57:29 +0100 changelog: fix the diverted opener to accept more kwargs
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 11 Jan 2020 04:57:29 +0100] rev 44055
changelog: fix the diverted opener to accept more kwargs The current code prevent the use of `atomictemp` file with the changelog opener. I do not see a good reason for this limitation. Differential Revision: https://phab.mercurial-scm.org/D7831
Mon, 06 Jan 2020 08:08:06 +0100 revlog: reorder a conditionnal about revlogio
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 06 Jan 2020 08:08:06 +0100] rev 44054
revlog: reorder a conditionnal about revlogio if we are using REVLOGV0, we will not use a rust based index. This small line movement make it clearer. Differential Revision: https://phab.mercurial-scm.org/D7830
Fri, 10 Jan 2020 15:47:39 -0800 rebase: delete seemingly unnecessary needupdate()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 15:47:39 -0800] rev 44053
rebase: delete seemingly unnecessary needupdate() This seemed to be about checking that the user hasn't updated away when we asked them to resolve merge conflicts. These days we call `cmdutil.checkunfinished()` and refuse to update, so the user shouldn't be able to get into this state. `test-rebase-interruptions.t` actually has some tests where it disables the rebase extension in order to be allowed to do some of these updates. That still passes, but I wouldn't personally haved cared if that failed. Differential Revision: https://phab.mercurial-scm.org/D7825
Fri, 10 Jan 2020 13:24:25 -0800 workingctx: move setparents() logic from localrepo to mirror overlayworkingctx
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 13:24:25 -0800] rev 44052
workingctx: move setparents() logic from localrepo to mirror overlayworkingctx It would be nice to later be able to call `wctx.setparents()` whether `wctx` is a `workingctx` or an `overlayworkingctx`. Differential Revision: https://phab.mercurial-scm.org/D7823
Fri, 10 Jan 2020 21:41:28 -0800 overlayworkginctx: implement a setparents() to mirror dirstate.setparents()
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 21:41:28 -0800] rev 44051
overlayworkginctx: implement a setparents() to mirror dirstate.setparents() This lets us make the in-memory and on-disk code a bit more similar. I'll soon also implement setparents() on the regular workingctx. Differential Revision: https://phab.mercurial-scm.org/D7822
Fri, 10 Jan 2020 17:03:23 -0800 overlayworkingctx: default branch to base context's branch
Martin von Zweigbergk <martinvonz@google.com> [Fri, 10 Jan 2020 17:03:23 -0800] rev 44050
overlayworkingctx: default branch to base context's branch This matches what the dirstate does (it reuses working copy parent's branch unless told otherwise). By moving the default out of `rebase.commitmemorynode()`, it will let us clean that up better later. Differential Revision: https://phab.mercurial-scm.org/D7821
Thu, 09 Jan 2020 15:41:40 -0800 grep: speed up `hg grep --all-files some/path` by using ctx.matches(match)
Martin von Zweigbergk <martinvonz@google.com> [Thu, 09 Jan 2020 15:41:40 -0800] rev 44049
grep: speed up `hg grep --all-files some/path` by using ctx.matches(match) ctx.matches(match) avoids walking unintersting parts of the tree when using tree manifests. That can make a very big difference when grepping in a small subset of the tree (2.0s -> 0.7s in my case, but can of course be made more extreme by picking a smaller subset of files). Differential Revision: https://phab.mercurial-scm.org/D7820
Thu, 09 Jan 2020 14:19:20 -0500 fix: fix grammar/typos in hg help -e fix stable
timeless <timeless@mozdev.org> [Thu, 09 Jan 2020 14:19:20 -0500] rev 44048
fix: fix grammar/typos in hg help -e fix
Thu, 09 Jan 2020 10:17:10 -0500 py3: byteify the opener option to use `rust.index` to allow Rust revlogs
Matt Harbison <matt_harbison@yahoo.com> [Thu, 09 Jan 2020 10:17:10 -0500] rev 44047
py3: byteify the opener option to use `rust.index` to allow Rust revlogs It looks like this corresponds to the byteified key written in localrepo in 8042856c90b6. Differential Revision: https://phab.mercurial-scm.org/D7818
Fri, 27 Dec 2019 21:11:36 -0800 graft: use revset for intersecting with ancestor set
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Dec 2019 21:11:36 -0800] rev 44046
graft: use revset for intersecting with ancestor set This addresses a TODO added in a1381eea7c7d (graft: do not use `.remove` on a smart set (regression), 2014-04-28). Differential Revision: https://phab.mercurial-scm.org/D7806
Fri, 27 Dec 2019 21:11:33 -0800 graft: don't remove from a list in a loop
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Dec 2019 21:11:33 -0800] rev 44045
graft: don't remove from a list in a loop This addresses a TODO added in a1381eea7c7d (graft: do not use `.remove` on a smart set (regression), 2014-04-28). I couldn't measure any speedup. Differential Revision: https://phab.mercurial-scm.org/D7805
Fri, 27 Dec 2019 22:40:52 -0800 tests: avoid grafting the same change over and over
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Dec 2019 22:40:52 -0800] rev 44044
tests: avoid grafting the same change over and over The test case added in a1381eea7c7d (graft: do not use `.remove` on a smart set (regression), 2014-04-28) added a test case that grafted the same change (renaming 'a' to 'b') three times over. It had description "graft works on complex revset", but AFACT, all that it cared about was that some ancestor of the working copy was in the set of revisions to graft. So this patch changes the test to do that instead. (I plan to later make it so that grafting these renames on top of each won't create the empty commits they currently create.) Differential Revision: https://phab.mercurial-scm.org/D7804
Wed, 08 Jan 2020 20:23:24 -0500 py3: byteify some `ui.configbool()` parameters
Matt Harbison <matt_harbison@yahoo.com> [Wed, 08 Jan 2020 20:23:24 -0500] rev 44043
py3: byteify some `ui.configbool()` parameters This popped up in 8042856c90b6. Differential Revision: https://phab.mercurial-scm.org/D7817
Mon, 23 Dec 2019 17:47:31 +0100 rust-discovery: type alias for random generator seed
Georges Racinet <georges.racinet@octobus.net> [Mon, 23 Dec 2019 17:47:31 +0100] rev 44042
rust-discovery: type alias for random generator seed It just makes our life easier Differential Revision: https://phab.mercurial-scm.org/D7715
Fri, 27 Dec 2019 15:53:16 -0800 tests: split out another ~1/2 of test-graft.t
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Dec 2019 15:53:16 -0800] rev 44041
tests: split out another ~1/2 of test-graft.t The tests involving renames were also quite independent from the rest. Differential Revision: https://phab.mercurial-scm.org/D7803
Fri, 27 Dec 2019 15:39:48 -0800 tests: split out ~1/3 of test-graft.t
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Dec 2019 15:39:48 -0800] rev 44040
tests: split out ~1/3 of test-graft.t test-graft.t is ~2400 lines and takes 34s to run. This patch moves the last ~1/3 of it to a separate file. The parts now run in 22s + 13s. On top of that, we can remove the #testcases from the old file, so it's only 22s + 2*13s instead of the 2*34s it was before. Differential Revision: https://phab.mercurial-scm.org/D7802
Fri, 27 Dec 2019 14:08:02 -0800 overlwayworkingctx: remove doubly bad reference to wrapped ctx for copies
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Dec 2019 14:08:02 -0800] rev 44039
overlwayworkingctx: remove doubly bad reference to wrapped ctx for copies `_wrappedctx` lives on overlwayworkingctx, not on the repo object, so we should access it as `._wrappedctx`, not `._repo._wrappedctx`. More importantly, the overlayworkingctx is relative to its base, not including it, so the copies returned should not include copies made in the base. Differential Revision: https://phab.mercurial-scm.org/D7801
Fri, 27 Dec 2019 12:41:56 -0800 movedirstate: get copies from dirstate before setting parents
Martin von Zweigbergk <martinvonz@google.com> [Fri, 27 Dec 2019 12:41:56 -0800] rev 44038
movedirstate: get copies from dirstate before setting parents Setting dirstate parents can modify the copies recorded in the dirstate when there are two dirstate parents. I don't think we ever call movedirstate() when there is more than one parent, but it seems clearer to get the copies from the dirstate first anyway. Differential Revision: https://phab.mercurial-scm.org/D7800
Thu, 12 Dec 2019 14:31:11 -0800 fix: convert clang-format-ignorelist to use wildcards
Kyle Lippincott <spectral@google.com> [Thu, 12 Dec 2019 14:31:11 -0800] rev 44037
fix: convert clang-format-ignorelist to use wildcards It's very brittle to specify the exact filenames for these vendored/thirdparty libraries; when there's an upgrade, it's likely not going to be updated. Differential Revision: https://phab.mercurial-scm.org/D7619
Wed, 08 Jan 2020 11:59:32 -0500 packaging: update Ubuntu docker build dependencies to Python 3
Connor Sheehan <sheehan@mozilla.com> [Wed, 08 Jan 2020 11:59:32 -0500] rev 44036
packaging: update Ubuntu docker build dependencies to Python 3 Changeset 7574ccd87200f02e updated the Debian docker builds to Python 3. In doing so, the Ubuntu docker-based builds broke, as the Dockerfile does not include the new dependencies as specified in `contrib/packaging/debian/control`. This commit changes the dependencies in the Ubuntu Dockerfile template to their Python 3 equivalents, fixing `make docker-ubuntu-bionic`. Differential Revision: https://phab.mercurial-scm.org/D7810
Tue, 07 Jan 2020 12:09:36 +0100 mmap: add a size argument to mmapread
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 07 Jan 2020 12:09:36 +0100] rev 44035
mmap: add a size argument to mmapread With this argument, we can control the size of the mmap created. (previously it was always the whole file. Differential Revision: https://phab.mercurial-scm.org/D7808
(0) -30000 -10000 -3000 -1000 -240 +240 +1000 +3000 tip