- Feb 05, 2020
-
-
Augie Fackler authored
This also skips using diff() when all we care about is the filenames. I'm expecting the built in set logic to be plenty fast. For really large manifests with a matcher in play this should copy substantially less data around. Differential Revision: https://phab.mercurial-scm.org/D8082
-
- Feb 07, 2020
-
-
Pulkit Goyal authored
-
- Feb 06, 2020
-
-
Augie Fackler authored
All we care about is the filepaths, so this avoids a pointless copy of the manifest that we only used to extract matching filenames. Differential Revision: https://phab.mercurial-scm.org/D8090
-
- Jan 24, 2020
-
-
Raphaël Gomès authored
While we wait on a future patch that could verify that the paths passed to `DirsMultiset` have been audited, we still need to handle this error. This patch makes it easier to bubble up and makes the error clearer. Also, this patch introduces the `subslice_index` function that could be useful for other - albeit niche - purposes. Differential Revision: https://phab.mercurial-scm.org/D7921
-
- Jan 22, 2020
-
-
Matt Harbison authored
Otherwise the clone command will emit a long stacktrace if there is no `=` character. Differential Revision: https://phab.mercurial-scm.org/D7969
-
- Dec 13, 2019
-
-
Pierre-Yves David authored
The copies test we currently have usually focus on simple case that do not dive too much into longer chains involving merges. This new test file focus on extensive testing of these case to validate their behavior and make sure the various copies algorithm have the same behavior. And… actually these test are currently broken for the changeset centric algorithm since 99ebde4fec99, but it went undetected because these case were not tested. Differential Revision: https://phab.mercurial-scm.org/D8078
-
- Sep 18, 2019
-
-
Jörg Sonnenberger authored
Differential Revision: https://phab.mercurial-scm.org/D7733
-
- Feb 07, 2020
-
-
Julien Cristau authored
hghave --test-features calls it 90 times, each one calling hg --version which takes a tenth of a second on my workstation, adding up to about 10s win on test-hghave.t. Fixes https://bugs.debian.org/939756 Differential Revision: https://phab.mercurial-scm.org/D8092
-
- Jan 24, 2020
-
-
Martin von Zweigbergk authored
The responsibility for clearing it is now in `cmdutil.clearunfinished()`, so we shouldn't have to unlink it in `hg.clean()`. Differential Revision: https://phab.mercurial-scm.org/D7992
-
- Feb 04, 2020
-
-
Martin von Zweigbergk authored
The call to `y.ancestor(x)` triggered repo filtering, which we'd like to avoid in the simple `hg status --copies` case. Differential Revision: https://phab.mercurial-scm.org/D8071
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D8070
-
- Jan 21, 2020
-
-
Matt Harbison authored
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
-
Matt Harbison authored
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
-
Matt Harbison authored
This is less ugly than passing an open callback to the `httpsendfile` constuctor. Differential Revision: https://phab.mercurial-scm.org/D7961
-
- Jan 15, 2020
-
-
Martin von Zweigbergk authored
In the same vein as the previous patch. Differential Revision: https://phab.mercurial-scm.org/D7901
-
Martin von Zweigbergk authored
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
-
- Feb 05, 2020
-
-
Augie Fackler authored
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
-
- Feb 06, 2020
-
-
Kyle Lippincott authored
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
-
- Nov 17, 2019
-
-
Pierre-Yves David authored
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
-
- Nov 16, 2019
-
-
Pierre-Yves David authored
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
-
- Jan 25, 2020
-
-
Pierre-Yves David authored
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
-
- Nov 18, 2019
-
-
Pierre-Yves David authored
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
-
- Nov 16, 2019
-
-
Pierre-Yves David authored
Python3 is the future^W present, it is important to run tests with it too. Differential Revision: https://phab.mercurial-scm.org/D8013
-
- Jan 24, 2020
-
-
Pierre-Yves David authored
The run result are nicer to read with color. Differential Revision: https://phab.mercurial-scm.org/D8012
-
- Jan 25, 2020
-
-
Pierre-Yves David authored
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
-
- Feb 04, 2020
-
-
Jan Alexander Steffens (heftig) authored
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
-
- Jan 02, 2020
-
-
Kyle Lippincott authored
Differential Revision: https://phab.mercurial-scm.org/D8089
-
- Feb 04, 2020
-
-
Pierre-Yves David authored
Differential Revision: https://phab.mercurial-scm.org/D8075
-
Pierre-Yves David authored
Differential Revision: https://phab.mercurial-scm.org/D8074
-
- Feb 03, 2020
-
-
Pierre-Yves David authored
For some reason, we are also reading the local config in that function. Differential Revision: https://phab.mercurial-scm.org/D8073
-
- Feb 04, 2020
-
-
Pierre-Yves David authored
We wil need to respect this environment variable in more place. Differential Revision: https://phab.mercurial-scm.org/D8072
-
Matt Harbison authored
Otherwise this broke automation when not launched from `contrib/packaging`. Differential Revision: https://phab.mercurial-scm.org/D8068
-
- Jan 14, 2020
-
-
Raphaël Gomès authored
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
-
Raphaël Gomès authored
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
-
Raphaël Gomès authored
This changeset introduces the use of the `pretty_assertions` crate for easier to read test output. Differential Revision: https://phab.mercurial-scm.org/D7867
-
- Feb 05, 2020
-
-
Raphaël Gomès authored
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
-
- Jan 21, 2020
-
-
Pulkit Goyal authored
Looks like py3 raises AttributeError instead of ImportError. This is caught on windows. Differential Revision: https://phab.mercurial-scm.org/D7965
-
- Feb 05, 2020
-
-
Augie Fackler authored
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
-
Augie Fackler authored
Nothing used it. Differential Revision: https://phab.mercurial-scm.org/D8079
-
- Jan 29, 2020
-
-
Kyle Lippincott authored
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
-