- 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.
-
- 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.
-
- 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
-
- May 20, 2021
-
-
Matt Harbison authored
This should have been part of 5b3513177f2b. Differential Revision: https://phab.mercurial-scm.org/D10759
-
- Apr 19, 2021
-
-
Martin von Zweigbergk authored
This is part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan Differential Revision: https://phab.mercurial-scm.org/D10467
-
- 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
-
- Mar 10, 2021
-
-
Pierre-Yves David authored
The output was introduced in a4c19a162615 and is wrong and unstable. So we glob it as other part of these tests already do. Differential Revision: https://phab.mercurial-scm.org/D10153
-
- Feb 15, 2021
-
-
sliquister authored
I recommend looking at this with a diff that ignores indentation. The test changes are because localrepo.close() updates some cache, which appears happens earlier now on rollbacks or strips or something. The http changes are because httppeer.close() prints stats with --verbose. Differential Revision: https://phab.mercurial-scm.org/D9999
-
- 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
-
- 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
-
- Oct 23, 2020
-
-
Yuya Nishihara authored
I initially thought this is a py3-compat bug of passwordmgr._writedebug(), but actually returning (None, str) pair is wrong at all. HTTP authentication would continue with user="None" in that case. Since registering a password of user=None should also be wrong, this patch simply adds early return.
-
- 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
-
- 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 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).
-
- Feb 05, 2019
-
-
Matt Harbison authored
The digest handler calls into the password manager on its own, and it apparently expects strings. Perhaps the Basic authentication handler didn't hit this because of its manual password fetch and format in retry_http_basic_auth(). The `pycompat.bytesurl()` on the user and password just above the first url.py diff seems unnecessary, because the password proxy in ui is converting to bytes IIUC.
-
Matt Harbison authored
I suppose we could spin the client side extension off to a *.py file if it gets more use. I was basically just looking to avoid killing the server and relaunching it just to change authentication schemes, because that doesn't always work on Windows. The test changes capture the problem with py3.
-
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.
-
- Dec 19, 2018
-
-
Boris Feld authored
It's easier to conditionalize some of the environment variables per Mercurial version once there is only one value per line. Differential Revision: https://phab.mercurial-scm.org/D5453
-
- 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 17, 2018
-
-
Anton Shestakov authored
Support for bundle2 streaming clones has been shipped in Mercurial 4.5 (7eedbd5d4880), but was never activated by default. It's time to have more people use it. The new format allows streaming clones to transport cache (hooray for speed) and phaseroots (fixes phase-related issues). Changes in tests: bundle2 capabilities now have "stream=v2" (plus a '\n' as a separator) and therefore take 14 bytes more: "%0Astream%3Dv2". Tip for tests that have data encoded with CBOR: 0xd3 - 0xc5 = 14. $USUAL_BUNDLE2_CAPS$ replaces $USUAL_BUNDLE2_CAPS_SERVER$, which is the same thing, but without "stream=v2". Since streaming clones now also transfer caches, the reported byte and file counts are higher (e.g. 816 bytes in 9 files instead of 613 bytes in 4 files, a bit of --debug and manual math confirms that the caches take these extra 203 bytes in 5 files). Differential Revision: https://phab.mercurial-scm.org/D4680
-
- 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
-
- Aug 18, 2018
-
-
Matt Harbison authored
I figure cloning a remote repository is more common, thus it's more likely that some people might be relying on the less restrictive behavior. Additionally, `hg init` will also create more than one level of missing directories. I also have a use case for reading the subrepos from .hgsub, and sharing them into the normal nested location on the server. SCM Manager doesn't host subrepos in the normal nested location, which is nice for deduplicating the repository data, but confuses `hg verify`. Some of the subrepos are in the root of the repositories, while others are one or two directories deep. So not having to build up the parent path first is desirable.
-
Matt Harbison authored
I noticed that `hg share` is unable to create more than one missing directory on the path, and thought it was inconsistent with clone. It turns out that the path for copying/linking the remote store has the same limitation, but cloning from a remote repo doesn't.
-
- May 01, 2018
-
-
Gregory Szorc authored
The killdaemons hghave feature has returned True since it was introduced in 448d0c452140. As such, "#require killdaemons" has no effect and is superfluous. So we remove instances of it. Differential Revision: https://phab.mercurial-scm.org/D3442
-
- Apr 14, 2018
-
-
Augie Fackler authored
Differential Revision: https://phab.mercurial-scm.org/D3342
-
- 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
Working my down the long tail of test failures due to the simple store. We're now down to 38 failures with the simple store. Differential Revision: https://phab.mercurial-scm.org/D3096
-
- 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
-
- Jan 18, 2018
-
-
Boris Feld authored
The feature is now advertised and use. Updating the branchmap cache can be very expensive (up to minutes on large repository) and fetching revision branch data is about 80% of that. Exchanging the rev branch cache over the wire really help to recover from branch map invalidation. (There is a good chance other in flight chance would conflict on test-http-bad-server.t and other. So here is a small note to help update that test again: capabilities=19bytes, part-107bytes)
-
- Mar 05, 2018
-
-
Boris Feld authored
A batch commands encapsulate multiple other commands. We display a bit more details about what is actually batched if peer request tracking is set.
-
- 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
-
- 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.
-
- Jan 22, 2018
-
-
Gregory Szorc authored
Previously, enabling of stream clone over bundle2 was a server-side only change. And clients would only advertise bundle2 support for stream clones if an experimental config option was set. This situation wasn't forward compatible because in the future (when the feature is enabled on servers by default), an old client would send a request to the server but it wouldn't send its own bundle2 capability support for stream parts. Servers would have to infer that clients not sending this capability were old Mercurial clients that only sent the capability if the feature was explicitly enabled. Implicit and inferred behavior makes implementing servers hard. It's much better to be explicit about client features. We should either make the config option for bundle2 stream clones disable the feature client-side as well (so a server doesn't see a request from a client not advertising stream support). Or we should always advertise stream support if a client is willing to accept stream parts. Since I anticipating stabilizing stream clone support in bundle2 quickly, I think it's safe to always advertise client support in the bundle2 capabilities. So this commit changes things to do that. Because capabilities now vary between client and server, we had to create variations of the variable substitutions for those strings. Differential Revision: https://phab.mercurial-scm.org/D1931
-