- Feb 22, 2025
-
-
Pierre-Yves David authored
Same rational as the parent changeset.
-
- Oct 25, 2024
-
-
Pierre-Yves David authored
-
- Oct 24, 2024
-
-
Raphaël Gomès authored
The traceback differences between all supported Python versions is about to become insane to handle, so let's check what we're actually looking to check.
-
- Oct 23, 2024
-
-
Raphaël Gomès authored
This test is quite noisy, but the fix was very easy.
-
- Oct 02, 2024
-
-
Matt Harbison authored
The second and third one of these in `test-http-proxy.t` was failing on Windows. The others were found by grep and by failed tests when output was matched and an attempt was made to emit the mask pattern. The first clonebundles failure on Windows emitted: error fetching bundle: [WinError 10061] $ECONNREFUSED$ We should probably stringify that better to get rid of the "[WinError 10061]" part.
-
- Jun 26, 2023
-
-
kiilerix authored
Testing on Fedora 38 failed with: egrep: warning: egrep is obsolescent; using grep -E The warning comes from https://git.savannah.gnu.org/cgit/grep.git/commit/?id=a9515624709865d480e3142fd959bccd1c9372d1 . For further anecdotal evidence of the change, see https://www.phoronix.com/news/GNU-Grep-3.8-Stop-egrep-fgrep . This reverses the code check that goes back to e7d3b509af8b. grep -E is POSIX, but there is a risk that it doesn't work the same on all platforms - especially older Unix versions. It should however always be possible to put a GNU grep in $PATH before running the tests.
-
- Feb 28, 2023
-
-
Matt Harbison authored
The LFS extension requires this, and if it isn't enabled on the client (or the LFS extension isn't loaded), a web client gets a 500 instead of a sensible error message. Now it gets a different (client) error, but maybe it can be handled more gracefully. c0f11347b107 indicates that treemanifest repos have this issue too. 29cfc474c5fd mentions gating this behind `experimental` so that the format could change, but that was 7 years ago and we now have an experimental `changegroup4` as well. We can keep this as a config for the next cycle in case someone runs into an unexpected problem, and then jettison it if the infinitepush bundle name changes are either acceptable as-is or can be created differently.
-
- Jan 31, 2023
-
-
Pierre-Yves David authored
-
- Jan 09, 2023
-
-
Anton Shestakov authored
-
- Jan 04, 2023
-
-
Matt Harbison authored
Presumably these were paired with `(no-py3 !)` at one point, but now they were unconditionally true. test-check-code.t required a couple of `(glob)` markers on the changed lines in test-lfs-serve-access.t, because of the `$LOCALIP` usage on those lines. Not sure how those lines slipped through the checks previously.
-
- Feb 20, 2022
-
-
Gregory Szorc authored
I simply did a search for `^.* \(no-py3 !\)\n` and removed all matched lines. There are still some references to no-py3. But these were the simpler ones to match against. Differential Revision: https://phab.mercurial-scm.org/D12253
-
- Mar 04, 2021
-
-
Jörg Sonnenberger authored
Since Mercurial 5.7, the corresponding bundle part is ignored as redundant. Stop advertising it so that peers don't have to spend time creating or transfering it. Differential Revision: https://phab.mercurial-scm.org/D10114
-
- Jan 15, 2021
-
-
Pierre-Yves David authored
This work around any deviciency/limitation of the clone process. In our case this ensure the persistent nodemap exist with valid content. Ideally, the cloning process would also do "the right thing". However since older server will never be able to do "the right thing". The local workaround will be necessary anyway. I am not worried by the performance impact of this as `hg clone` is non-instant on large repositories where is could matters. Warming the cache if they are already correct is very fast. And if they are not already warm, this seems like a good time to do so. This impact various test as more cache are now warmed sooner, all the change should be harmless. Differential Revision: https://phab.mercurial-scm.org/D9789
-
- Dec 10, 2020
-
-
Martin von Zweigbergk authored
This is done as part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9601
-
- Nov 23, 2020
-
-
Martin von Zweigbergk authored
Some types of exceptions had a trailing "!" printed after the message from the exception itself. I guess some of these errors seem a little more severe (?), but it seems more likely that the inconsistency was just an oversight. Differential Revision: https://phab.mercurial-scm.org/D9378
-
- Feb 26, 2020
-
-
sliquister authored
The motivation is simply to make hg work better out of the box. This is a slight backwards compatibility break, because client extensions could have assumed that the list of heads the client sees during discovery will be the list of heads during the entirety of the push. It seems unlikely to matter, and not worth mentioning. There's a fair amount of diff in tests, but this is just due to sending a few more bytes on the wire, except for test-acl.t. The extra "invalid branch cache" lines in test-acl.t don't seem to indicate a problem: the branchcache now get computed during the bundle application (because of the check:updated-heads bundle part), but doesn't get rolled back when transactions rollback, thus causing a message in the next operation computing the branch cache. Before this change, I assume the branchcache was only computed on transaction commit, so not computed at all when the transactions roll back, thus no messages. Differential Revision: https://phab.mercurial-scm.org/D8202
-
- 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
-
- Jan 18, 2020
-
-
Gregory Szorc authored
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
-
- Jan 15, 2020
-
-
Matt Harbison authored
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
-
- Dec 06, 2019
-
-
Paul Sonnenschein authored
Fixes test failures on hurd-i386 Ref: https://bugs.debian.org/946178 Differential Revision: https://phab.mercurial-scm.org/D7556
-
- Nov 04, 2019
-
-
Denis Laxalde authored
This improves the rendering of some exceptions by avoiding raw bytestrings, especially when using --traceback option.
-
Denis Laxalde authored
Similar to a973a75e92bf or 3e9c6cef949b.
-
- Oct 06, 2019
-
-
Augie Fackler authored
This is using my patch to black (https://github.com/psf/black/pull/826) so we don't un-wrap collection literals. Done with: hg files 'set:**.py - mercurial/thirdparty/** - "contrib/python-zstandard/**"' | xargs black -S # skip-blame mass-reformatting only # no-check-commit reformats foo_bar functions Differential Revision: https://phab.mercurial-scm.org/D6971
-
- Sep 11, 2019
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D6850
-
- Sep 08, 2019
-
-
Pierre-Yves David authored
Before that, applying multiple changegroups in the same transaction issued the message multiple time. This result in a confusing output: adding changesets adding manifests adding file changes added 32768 changesets with 60829 changes to 2668 files adding changesets adding manifests adding file changes added 8192 changesets with 16885 changes to 1553 files adding changesets adding manifests adding file changes added 1020 changesets with 1799 changes to 536 files adding changesets adding manifests ... Instead, we now only issue the message once at the end of the transaction, summing up all added changesets, changes and files. The line is identical, but happens sightly later in the output. There are other suboptimal behavior around issue multiple changegroup (eg: progress bar). We'll cover them later. This impact of lot of test as one would expect, but a two pass check show they are just the order change we expected. To deal with "under the hood" bundle application by internal code, we had to take a slightly hacky move. We could clean that up with a more official way to enter "under the hood" section, however I want to keep this series simple to get it landed. This kind of change have a very high bit rot rate since it impact a lot of test output.
-
- Feb 11, 2019
-
-
Augie Fackler authored
-
- Feb 07, 2019
-
-
Mathias De Mare authored
Differential Revision: https://phab.mercurial-scm.org/D5877
-
Matt Harbison authored
I ran into a problem pushing to an old Apache server- the normal outgoing traffic occurred, the Batch API request and response occurred, and then things suddenly halted. 5 minutes later, a 500 was returned, and the server log had a timeout reading 32K from `self._req.bodyfh` in hgweb.request.sendresponse(). Watching in WireShark, the Batch API got a 401, retried properly, then proceeded to PUT the blob (without authentication headers). This got a 401, but the client never retried with authentication. Worse, the blob was sent over the wire in the failed attempt. This kills digests for both the Batch API and the Transfer API. While in theory we could have the Batch API provide external URLs to a place that supports Basic Authentication, the LFS spec actually calls out using Basic Authentication[1]. It's not clear to me if they've been able to shoehorn in other methods. But let's keep it simple until somebody needs it. If we only had to support python2, we could just not add the handler for digest authentication. However in python3, AbstractBasicAuthHandler raises ValueError if it sees a scheme other than Basic. So we need to intercept all other schemes before it gets to that point. # no-check-commit because of urllib2.OpenerDirector foo_bar calling conventions [1] https://github.com/git-lfs/git-lfs/blob/master/docs/api/authentication.md
-
- Feb 05, 2019
-
-
Matt Harbison authored
We had 4 copy/pastes of this, and no coverage for http digests (which are currently broken on py3).
-
- Jan 28, 2019
-
-
Matt Harbison authored
I'm not sure why the one stackframe is py2 only, but that seems harmless. The remaining failure is LfsCorruptionError printing the fully qualified name, as well as b'' around its message.
-
- Jan 27, 2019
-
-
Matt Harbison authored
This is almost entirely b'' prefixing, with a couple of exceptions forced to bytes. Much of this is also borrowed from Augie's code. There's an HTTPError.read() that I flagged that I assume needs to be converted to bytes, but I can't find confirmation. Handling the deserialized JSON object over several functions made r'' vs b'' accesses confusing, so this assumes that the JSON object will be converted to bytes immediately. That will be done in the following commits, so it's not buried in these trivial changes.
-
Matt Harbison authored
-
- Dec 28, 2018
-
-
Matt Harbison authored
9.5 years should be enough time, but there were some tests for the old style still (which are now updated). Exthelper doesn't fallback to the old API, so this is for consistency. .. api:: The extension hook ``extsetup`` without a `ui` argument has been deprecated, and will be removed in the next version. Add a `ui` argument to avoid the deprecation warning.
-
- Dec 10, 2018
-
-
Boris Feld authored
We have a CI job that runs the Mercurial tests in parallel. Some of the network related failures seems to be different on the environment. Oddly, those failures happens only when running the tests in parallel, not when running the test file only. I have no idea how to get the windows formatted message for the error, if someone could give me an hand, I will update this changeset with the value. Differential Revision: https://phab.mercurial-scm.org/D5401
-
- Nov 15, 2018
-
-
Matt Harbison authored
I don't love that it repeats 'HTTP Error' in an already long message, but I doubt that we should assume that it will always say that on the original exception message.
-
Matt Harbison authored
Sometimes the blob server is hit first (e.g. on push), and sometimes it's hit last (e.g. pull). Throw in depth first subrepo operations, and things quickly get insane. It wasn't even mentioning LFS, so just saying "connection refused" can be confusing- especially if the blob server is a secondary server and connecting to the repo server works. The exception handler for the transfer handler will print the full path to the blob, but that seems fine given that it might be necessary to debug a second server. (We don't yet support a standalone blob server, so the handler for the Batch API will cover 99.9% of the current problems. But it might as well be handled now while I'm thinking about it.) The function for translating to a message was mostly borrowed from scmutil.catchall().
-
Matt Harbison authored
The previous message was too debug-ish and less action oriented than a hint should be. The remaining errors that aren't handled are more along the lines of programming errors (not using POST, bad accept type, etc), so I'm not bothering with that. The friendly errors purposely use `self.baseurl` instead of the full Batch API endpoint because I'd expect some copy/paste/modify on the part of the user here, and it would be more confusing if '/objects/batch' magically appeared, but shouldn't be used in the config setting. It still seems like the right thing for debugging in the catchall case.
-
Matt Harbison authored
A coworker had a typo in `lfs.url`, forgot it was even set because usually the blob server is inferred, and then got a 404. It would have been easier to debug with the failing URL printed.
-
- Sep 21, 2018
-
-
Matt Harbison authored
This is based on a patch by Gregory Szorc. I made small adjustments to clean up the messaging when the server has the extension enabled, but the client has it disabled (to prevent autoloading). Additionally, I added a second server capability to distinguish between the server having the extension enabled, and the server having LFS commits. This helps prevent unnecessary requirement propagation- the client shouldn't add a requirement that the server doesn't have, just because the server had the extension loaded. The TODO I had about advertising a capability when the server can natively serve up blobs isn't relevant anymore (we've had 2 releases that support this), so I dropped it. Currently, we lazily add the "lfs" requirement to a repo when we first encounter LFS data. Due to a pretxnchangegroup hook that looks for LFS data, this can happen at the end of clone. Now that we have more control over how repositories are created, we can do better. This commit adds a repo creation option to add the "lfs" requirement. hg.clone() sets this creation option if the remote peer is advertising lfs usage (as opposed to just support needed to push). So, what this change effectively does is have cloned repos automatically inherit the "lfs" requirement. Differential Revision: https://phab.mercurial-scm.org/D5130
-
- Oct 01, 2018
-
-
Gregory Szorc authored
Now that keepalive.py records HTTP request count and the number of bytes sent and received as part of performing those requests, we can easily print a report on the activity when closing a peer instance! Exact byte counts are globbed in tests because they are influenced by non-deterministic things, such as hostnames and port numbers. Plus, the exact byte count isn't too important anyway. I feel obliged to note that printing the byte count could have security implications. e.g. if sending a password via HTTP basic auth, the length of that password will influence the byte count and the reporting of the byte count could be a side-channel leak of the password length. I /think/ this is beyond our threshold for concern. But if we think it poses a problem, we can teach the byte count logging code to e.g. ignore sensitive HTTP request headers. We could also consider not reporting the byte count of request headers altogether. But since the wire protocol uses HTTP headers for sending command arguments, it is kind of important to report their size. Differential Revision: https://phab.mercurial-scm.org/D4858
-