- Feb 22, 2025
-
-
Pierre-Yves David authored
Same rational as the parent changeset.
-
- Nov 28, 2024
-
-
Pierre-Yves David authored
Strictly speaking we could also do that for v1, but that is old enough that I don't want to bother.
-
- Dec 11, 2023
-
-
Pierre-Yves David authored
The test suite mostly use small repositories, that implies that most changelog in the tests are inlined. As a result, non-inlined changelog are quite poorly tested. Since non-inline changelog are most common case for serious repositories, this lack of testing is a significant problem that results in high profile issue like the one recently fixed by 66417f55ea33 and 849745d7da89. Inlining the changelog does not bring much to the table, the number of total file saved is negligible, and the changelog will be read by most operation anyway. So this changeset is make it so we never inline the changelog, and de-inline the one that are still inlined whenever we touch them. By doing that, we remove the "dual code path" situation for writing new entry to the changelog and move to a "single code path" situation. Having a single code path simplify the code and make sure it is covered by test (if test cover that situation obviously) This impact all tests that care about the number of file and the exchange size, but there is nothing too complicated in them just a lot of churn. The churn is made "worse" by the fact rust will use the persistent nodemap on any changelog now. Which is overall a win as it means testing the persistent nodemap more and having less special cases. In short, having inline changelog is mostly useless and an endless source of pain. We get rid of it.
-
- May 02, 2022
-
-
Raphaël Gomès authored
This reduces a lot of the test output that was otherwise useless, and also makes it a lot easier to add things to verify without breaking the test suite because of additional output.
-
- Jan 24, 2022
-
-
Pierre-Yves David authored
The `supportedformat` requirements is missing some important requirements and it seems better to filter out with all requirements we know, not just an "arbitrary" subset. The `supportedformat` set is lacking some important requirements (for example `revlog-compression-zstd`). This is getting fixed on default (for Mercurial 6.1) However, fixing that in 6.1 means the stream requirements sent over the wire will contains more items. And if we don't apply this fix on older version, they might end up complaining about lacking support for feature they actually support for years. This patch does not fix the deeper problem (advertised stream requirement lacking some of them), but focus on the trivial part : Lets use the full set of supported requirement for looking for unsupported ones. This patch should be simple to backport to older version of Mercurial and packager should be encouraged to do so. This is a graft of d9017df70135 from default. Differential Revision: https://phab.mercurial-scm.org/D12091
-
- Aug 25, 2021
-
-
Pierre-Yves David authored
Touching `test-clone-stream.t` is very painful otherwise. Differential Revision: https://phab.mercurial-scm.org/D11337
-
- May 20, 2021
-
-
Matt Harbison authored
This should have been part of 5b3513177f2b. Differential Revision: https://phab.mercurial-scm.org/D10759
-
- Apr 06, 2021
-
-
Pierre-Yves David authored
As see in changeset bb271ec2fbfb, zstd is 20% to 50% faster for reading and writing. Use take advantage of the new config behavior to try zstd by default, falling back to zlib is zstd is not available on that plateform. Differential Revision: https://phab.mercurial-scm.org/D10326
-
- Oct 22, 2020
-
-
Martin von Zweigbergk authored
This is per https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9309
-
- Feb 09, 2019
-
-
Pierre-Yves David authored
There is no reason to not include the txnname alongside the txnid in all case. The python hooks already have them, so aligning the the shell hooks seems it could be useful in the future. (I don't have a strong opinion about this, we can also decide to never align the python and shell hooks and this and I'll drop this patch).
-
Boris Feld authored
This makes the output easier to update and read.
-
- 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).
-
- 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.
-
- Nov 16, 2018
-
-
Matt Harbison authored
I ran into a problem where I tried updating to a different branch, and the process appeared to hang. It turned out that the subrepo revision wasn't available locally, and I must have originally cloned it from an `hg serve -S` on a machine that currently wasn't serving anything. It took 2+ minutes to timeout, and didn't mention what it was connecting to even then. There are a couple of other issues in this scenario too. - The repo is dirty after the failed checkout because the top level repo is updated first. We should probably make 2 passes- top down to pull everything needed, and then do an update once everything is in place. - Something must be reading .hgsubstate from wdir because if the same merge command is run after the timeout, a prompt is issued that the local and remote subrepo diverged, instead of hanging. But it lists the local version and remote version as having the same hash.
-
- Sep 04, 2018
-
-
Meirambek Omyrzak authored
output before: "500 files, 2035 changesets, 2622 total revisions" output after: "checked 2035 changesets with 2622 changes to 500 files" new one was suggested in the comments inside the issue. Differential Revision: https://phab.mercurial-scm.org/D4476
-
- Apr 14, 2018
-
-
Augie Fackler authored
# skip-blame just b prefixes Differential Revision: https://phab.mercurial-scm.org/D3366
-
- Apr 12, 2018
-
-
Gregory Szorc authored
We were calling the remote command twice without mutation the remote in between. Derp. Differential Revision: https://phab.mercurial-scm.org/D3287
-
- Apr 11, 2018
-
-
Gregory Szorc authored
We don't need to be advertising client protocol parameters as part of the capabilities request during the handshake because nothing in version 1 of the wire protocol will use this data. i.e. the advertisement is wasteful. Differential Revision: https://phab.mercurial-scm.org/D3241
-
- Jan 18, 2018
-
-
Jörg Sonnenberger authored
Pullbundles are similar to clonebundles, but served as normal inline bundle streams. They are almost transparent to the client -- the only visible effect is that the client might get less changes than what it asked for, i.e. not all requested head revisions are provided. The client announces support for the necessary retries with the partial-pull capability. After receiving a partial bundle, it updates the set of revisions shared with the server and drops all now-known heads from the request list. It will then rerun getbundle until no changes are received or all remote heads are present. Extend badserverext to support per-socket limit, i.e. don't assume that the same limits should be applied to all sockets. Differential Revision: https://phab.mercurial-scm.org/D1856
-
- Apr 04, 2018
-
-
Gregory Szorc authored
We mass disabled stream clone tests in a previous commit. Looks like one was missed. Differential Revision: https://phab.mercurial-scm.org/D3110
-
- Apr 03, 2018
-
-
Gregory Szorc authored
There are a handful of test failures in the simple store with regards to stream clones. Fixing them will require a lot of conditional output. Disabling the tests wholesale is easier at this juncture. Differential Revision: https://phab.mercurial-scm.org/D3064
-
- Mar 11, 2018
-
-
Gregory Szorc authored
We're trying to remove ``wsgirequest``. The permissions hooks don't do anything they can't do with our new request type. So let's pass that in. This was the last use of ``wsgirequest`` in the wire protocol code! .. api:: hgweb.hgweb_mod.permhooks no longer take a ``wsgirequest`` instance as an argument. Differential Revision: https://phab.mercurial-scm.org/D2793
-
- Mar 06, 2018
-
-
Gregory Szorc authored
There were a handful of merge conflicts in the wire protocol code due to significant refactoring in default. When resolving the conflicts, I tried to produce the minimal number of changes to make the incoming security patches work with the new code. I will send some follow-up commits to get the security patches better integrated into default.
-
- Feb 21, 2018
-
-
Gregory Szorc authored
The permissions model of hgweb relies on a dictionary to declare the operation associated with each command - either "pull" or "push." This dictionary was established by d3147b4e3e8a in 2008. Unfortunately, we neglected to update this dictionary as new wire protocol commands were introduced. This commit defines the operations of most wire protocol commands in the permissions dictionary. The "batch" command is omitted because it is special and requires a more complex solution. Since permissions checking is skipped unless a command has an entry in this dictionary (this security issue will be addressed in a subsequent commit), the practical effect of this change is that various wire protocol commands now HTTP 401 if web.deny_read or web.allow-pull, etc are set to deny access. This is reflected by test changes. Note how various `hg pull` and `hg push` operations now fail before discovery. (They fail during the initial "capabilities" request.) This change fixes a security issue where built-in wire protocol commands would return repository data even if the web config were configured to deny access to that data. I'm on the fence as to whether we should HTTP 401 the capabilities request. On one hand, it can expose repository metadata and can tell callers things like what version of Mercurial the server is running. On the other hand, a client may need to know the capabilities in order to authenticate in a follow-up request. It appears that Mercurial clients handle the HTTP 401 on *any* protocol request, so we should be OK sending a 401 for "capabilities." But if this causes problems, it should be possible to allow "capabilities" to always work. .. bc:: Various read-only wire protocol commands now return HTTP 401 Unauthorized if the hgweb configuration denies read/pull access to the repository. Previously, various wire protocol commands would still work and return data if read access was disabled.
-
- Feb 17, 2018
-
-
Augie Fackler authored
# skip-blame just some b prefixes Differential Revision: https://phab.mercurial-scm.org/D2293
-
- Dec 03, 2017
-
-
Matt Harbison authored
I suspect some more of these are globbed out, so this is a bit of future proofing.
-
- Nov 05, 2017
-
-
Boris Feld authored
We mass update the tests now. This will help the next soul touching the http protocol.
-
- Oct 12, 2017
-
-
Denis Laxalde authored
Upon pull or unbundle, we display a message with the range of new revisions fetched. This revision range could readily be used after a pull to look out what's new with 'hg log'. The algorithm takes care of filtering "obsolete" revisions that might be present in transaction's "changes" but should not be displayed to the end user.
-
- Oct 05, 2017
-
-
Saurabh Singh authored
chg only supports 'hg serve' when the options to the serve command follow the 'hg serve'. For example, 'hg -R <repo> serve ..' is unsupported. This leads to issues with chg running for the following tests: - test-bundle2-exchange.t - test-clone-uncompressed.t - test-hgweb-csp.t - test-http-bad-server.t - test-http-bundle1.t - test-http-protocol.t - test-http.t There was an effort made earlier to fix this issue for chg and the tests were fixed to confirm to the compatible pattern. But the new tests did not take care of the same and hence, fail. Hopefully, there will be continuous build setup for chg after all tests are made compatible with chg so that we can avoid such issues. Test Plan: Ran the aforementioned tests with and without '--chg' option. Differential Revision: https://phab.mercurial-scm.org/D946
-
- Oct 01, 2017
-
-
Gregory Szorc authored
--uncompressed isn't a very good name and its description in the help documentation isn't very useful. We refer to this concept as "stream clones" in a number of places. I think it makes sense to change the user-facing argument to use the mode --stream. So this commit does that. We keep --uncompressed around for backwards compatibility. While we're here, we overhaul the help docs for streaming clones to be somewhat useful. All tests have been updated to reflect the new preferred --stream argument. A test for backwards compatibility of --uncompressed has been added. .. bc:: `hg clone --stream` should now be used instead of --uncompressed. --uncompressed is marked as deprecated and is an alias for --stream. There is no schedule for elimination of --uncompressed. Differential Revision: https://phab.mercurial-scm.org/D864
-
- May 11, 2017
-
-
Siddharth Agarwal authored
For large enough repositories, pull-based clones take too long, and an attempt to use them indicates some sort of configuration or other issue or maybe an outdated Mercurial. Add a config option to disable them.
-
- May 09, 2017
-
-
Siddharth Agarwal authored
This helps both users and the people who support them figure out why a stream clone couldn't be performed. In an upcoming patch we're going to add a way for servers to hard abort on a full getbundle. In those cases servers might expect clients to perform a stream clone, so it's important to communicate why one couldn't be done.
-
Siddharth Agarwal authored
Turns out we had no coverage for this important case.
-
- Mar 31, 2017
-
-
Pierre-Yves David authored
While we are here, we can also add the hook name information to external hook.
-
Pierre-Yves David authored
The python hooks have access to the hook type information. There is not reason for external hook to not be aware of it too. For the record my use case is to make sure a hook script is configured for the right type.
-
- Mar 30, 2017
-
-
Pierre-Yves David authored
Hooks related to the transaction are aware of the transaction id. By definition this txn-id is unique and different for each transaction. As a result it can never be predicted in test and always needs matching. As a result, touching any like with this data is annoying. We solve the problem once and for all by installing an automatic replacement. In test, this will now show as: TXNID=TXN:$ID$
-
- Feb 16, 2017
-
-
Jun Wu authored
Previously, "hg serve" will listen on "", which is not clear which interface it will actually listen on - it could listen on all interfaces (ex. 0.0.0.0 on IPv4). The run-tests.py script only checks "localhost" for available ports. So let's make it the same for "hg serve" by explicitly setting "web.address" to "localhost". This resolves some IPv6 EADDRINUSE errors.
-
- Feb 10, 2017
-
-
Pierre-Yves David authored
Previously Abort raised during 'getbundle' call poorly reported (HTTP-500 for http, some scary messages for ssh). Abort error have been properly reported for "push" for a long time, there is not reason to be different for 'getbundle'. We properly catch such error and report them back the best way available. For bundle, we issue a valid bundle2 reply (as expected by the client) with an 'error:abort' part. With bundle1 we do as best as we can depending of http or ssh.
-
- Dec 24, 2016
-
-
Gregory Szorc authored
Now that servers expose a capability indicating they support application/mercurial-0.2 and compression, clients can key off this to say they support responses that are compressed with various compression formats. After this commit, the HTTP wire protocol client now sends an "X-HgProto-<N>" request header indicating its support for "application/mercurial-0.2" media type and various compression formats. This commit also implements support for handling "application/mercurial-0.2" responses. It simply reads the header compression engine identifier then routes the remainder of the response to the appropriate decompressor. There were some test changes, but only to logging. That points to an obvious gap in our test coverage. This will be addressed in a subsequent commit once server support is in place (it is hard to test without server support).
-
- Oct 28, 2016
-
-
Katsunori FUJIWARA authored
On Windows platform, invoking printenv.py directly via hook is problematic, because: - unless binding between *.py suffix and python runtime, application selector dialog is displayed, and running test is blocked at each printenv.py invocations - it isn't safe to assume binding between *.py suffix and python runtime, because application binding is easily broken For example, installing IDE (VisualStudio with Python Tools, or so) often requires binding between source files and IDE itself. This patch invokes printenv.py via sh -c for test portability. This is a kind of follow up for d19787db6fe0, which eliminated explicit "python" for printenv.py. There are already other 'sh -c "printenv.py"' in *.t files, and this fix should be reasonable. This changes were confirmed in cases below: - without any application binding for *.py suffix - with binding between *.py suffix and VisualStudio This patch also replaces "echo + redirection" style with "heredoc" style, because: - hook command line is parsed by cmd.exe as shell at first, and - single quotation can't quote arguments on cmd.exe, therefore, - "printenv.py foobar" should be quoted by double quotation, but - nested quoting (or tricky escaping) isn't readable
-