- Feb 22, 2025
-
-
Pierre-Yves David authored
Same rational the parent changesets.
-
Pierre-Yves David authored
Same rational as the parent changeset.
-
- Sep 25, 2024
-
-
Pierre-Yves David authored
The new file can be memorymapped, while the old one cannot. So there is value in having the v2 format around as soon a possible.
-
- Sep 24, 2024
-
-
Pierre-Yves David authored
We want to ensure no older clients will truncate the file under us. So we need to change their name. We don't change the rest of the format (unfortunaly).
-
- Sep 23, 2024
-
-
Pierre-Yves David authored
Truncating the file prevent the safe use of mmap. So instead of overwrite the existing data. If more than 20% of the file is to be overwritten, we rewrite the whole file instead. Such whole rewrite is done by replacing the old one with a new one, so mmap of the old file would be affected. This prepare a more aggressive use of mmap in later patches.
-
Pierre-Yves David authored
This seems useful to be able to do this, for example during strip. This align with the intended expressed in the `test-branches.t` test. This will help use being more confident about future changes in the series.
-
- Jul 10, 2023
-
-
Pierre-Yves David authored
This is as valid and simpler, it will help us to eventually get ride of `safehasattr`.
-
- 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.
-
- Feb 20, 2022
-
-
Gregory Szorc authored
This is no longer required since we require Python 3 and the linter no longer requires these statements. Differential Revision: https://phab.mercurial-scm.org/D12255
-
- Sep 28, 2021
-
-
Martin von Zweigbergk authored
Same reasoning as for `revrange()` in an earlier patch. Differential Revision: https://phab.mercurial-scm.org/D11562
-
- Jan 29, 2021
-
-
Martin von Zweigbergk authored
A hook can be used for checking inputs, state, configuration, security, etc., so it's unclear which of the existing exit codes to use. Let's instead add one specifically for failed hooks. I picked 40. Differential Revision: https://phab.mercurial-scm.org/D9910
-
- Jan 14, 2021
-
-
Martin von Zweigbergk authored
Command errors (unknown or ambiguous commands, or bad command arguments or options) are handled in the `dispatch` module. Most other errors are handled in the `scmutil` module. This patch therefore has to duplicate a little bit of code from the `scmutil` module. It's just a few lines, however, so it seems fine to me. It's a pretty common category of errors, so it's important to have them respect `ui.detailed-exit-code`. Differential Revision: https://phab.mercurial-scm.org/D9777
-
- 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
-
- Nov 08, 2020
-
-
sliquister authored
As discussed at the 5.2 sprint, replace strip extension by a core command, debugstrip. Obviously, the extension stays for backwards compatibility. As an implementation note, I moved the strip file as is into core, which is not done elsewhere, AFAIK. I could have inlined it into debugcommands, but that doesn't sound great. Differential Revision: https://phab.mercurial-scm.org/D9285
-
- Oct 12, 2020
-
-
Martin von Zweigbergk authored
This very similar to an earlier patch (which was for `InputError`). In this patch, I also updated the transplant extension only because `test-transplant.t` would otherwise have needed a `#if continueflag`. Differential Revision: https://phab.mercurial-scm.org/D9310
-
- Sep 18, 2020
-
-
Pierre-Yves David authored
The current code was blink to change from other branches when stripping merges that are ancestors of the working copy parents.
-
Pierre-Yves David authored
When using `hg strip --keep` on a set of changeset that contains a merge, the set of file considered when rebuilding the dirstate is missing files updated by changeset that are not directly inside the `new-parent::old-parent` range. We start with updating the test with new output highlighting the issue. This issue was spotted because that dirstate inconsistency made the test flaky. The new command make the test less flaky (but still wrong).
-
- Jan 29, 2020
-
-
Martin von Zweigbergk authored
This lets the user more easily find the commit that is involved in the conflict, such as the source of `hg update -m` or the commit being grafted by `hg graft`. Differential Revision: https://phab.mercurial-scm.org/D8043
-
Martin von Zweigbergk authored
The next commit will change the behavior for these. I've used slightly different commands in the different tests to match the surrounding style. Differential Revision: https://phab.mercurial-scm.org/D8042
-
- Aug 01, 2019
-
-
Pierre-Yves David authored
While debugging some test failure, I released the test never checks if the relevant changesets were preserved. So I am updating the test from `hg parents` usage to `hg log -G` with a special template. This increase the area covered by the test and clarify the test failures.
-
- Jul 15, 2019
-
-
Martin von Zweigbergk authored
`"%s" % None` does not work on py3. I've extracted a little function for producing a formatted message given the filter name. Differential Revision: https://phab.mercurial-scm.org/D6644
-
- Jun 08, 2019
-
-
Taapas Agrawal authored
This removes `STATES` from `state.py` and adds support to `statecheck` class to handle its features. `getrepostate()` function is modified accordingly. This adds a method 'cmdutil.addunfinished()' for appending to the unfinishedstate list so as to keep 'merge' and 'bisect' at the last. This also makes two separate message formats for `checkunfinished()` and `getrepostate()` as there were previously present. Results of test changed are shown. Differential Revision: https://phab.mercurial-scm.org/D6503
-
- Jun 17, 2019
-
-
Martin von Zweigbergk authored
This also means that we get the standard error messages (see changed test cases). Differential Revision: https://phab.mercurial-scm.org/D6535
-
- Jun 14, 2019
-
-
Taapas Agrawal authored
This ensures to abort strip to `hg strip` when we have a merge in progress and allow it only when a `--force` flag is used. Differential Revision: https://phab.mercurial-scm.org/D6529
-
- Oct 17, 2018
-
-
Anton Shestakov authored
Apart from looking better in hg help command, these strings are also helpful when generating shell completions programmatically.
-
- Sep 26, 2018
-
-
Boris Feld authored
The `cleanupnodes` has logic to skip the creation of "prune" markers if the changeset is already obsolete. This feels strange and gets in the way of code changes to tracks folds. Now that callers no longer request such prune, we can drop this logic. In many cases, pruning through cleanupnodes should be replaced by internal phase usage.
-
- Aug 29, 2018
-
-
Boris Feld authored
When interacting with non-publishing repository or bundle, it is useful to have some information about the phase of the changeset we just pulled. This changeset updates the "new changesets MIN:MAX" output to also includes phases information for non-public changesets. Displaying extra data about non-public changesets means the output for exchange with publishing repository (the default) is unaffected.
-
- Jul 05, 2018
-
-
Sushil Khanchi authored
Help text is modified to clearly define the meaning of --no-backup option. Differential Revision: https://phab.mercurial-scm.org/D3886
-
- May 08, 2018
-
-
Boris Feld authored
It blocks old clients to read bundle including this part. Differential Revision: https://phab.mercurial-scm.org/D3481
-
Boris Feld authored
Most parts are mandatory but when introducing new parts, they should be advisory if included by default or old clients won't be able to process it. Differential Revision: https://phab.mercurial-scm.org/D3480
-
- 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
-
Gregory Szorc authored
Before, we used the default store, which was based on fncache and dotencode. After attempting to port tests to work with the simple store, I realized that fncache was more trouble than it is worth. This commit implements a proper store type for the simple repo - one that isn't based off fncache. This causes a number of new test failures because of tests expecting the full fncache store filename encoding. I may extend the store format in a subsequent commit to take the filename encoding parts of fncache that we can take (basically everything except hash encoding, since that isn't reversible). But for now, let's use encoded store. As part of this, we implement proper requirements support for repos created with the simple store. This should have been done from the beginning, as a requirement is needed to lock out clients that don't understand a storage format. A new hghave feature advertising the presence of fncache in repos has been added. Most tests touching the fncache are now conditional on that feature. Other tests have added the optional repo requirement to output. Differential Revision: https://phab.mercurial-scm.org/D3095
-
Gregory Szorc authored
~85 tests don't like our non-revlog file store for various reasons. This commit introduces hghave functionality for declaring and querying repository features. By default, we assume repositories have revlog-based file storage. But if the HGREPOFEATURES environment variable is set, we can override the default set of repository features. If you run the test harness with our simplestorerepo extension and an environment variable set to the proper value, you can override the hghave defaults to agree with simplestorerepo's version of reality. Various tests have been modified so behavior dependent on revlog-based file storage is marked as such. This fixes a handful of test failures with our custom file storage extension. But dozens remain. The point of this commit is to demonstrate how tests will need to be modified to account for custom storage implementations. TBH, I'm not convinced hghave is the proper layer for repository feature detection. I /think/ we'll eventually want something in run-tests.py itself. But that would require inventing a new primitive in the test harness. This is all very alpha at the moment. So I think hghave is an acceptable place to hang this feature detection. I think the right time to be thinking about integrating this into run-tests.py is *after* we have a stable alternate storage implementation in core. For now, let's try to make progress towards the idea of an alternate storage backend. Differential Revision: https://phab.mercurial-scm.org/D3030
-
- Apr 03, 2018
-
-
Gregory Szorc authored
`hg pull <bundle>` uses the special "bundlerepo" repository. The bundlerepo code makes many assumptions about the storage of repositories. It will be difficult to teach bundlerepo to use non-revlog storage before a better storage interface is established. Many test failures using our "simple store" are related to bundlerepo: the simple store just isn't compatible with bundlerepo because of storage assumptions in bundlerepo. In order to mitigate the impact of bundlerepo on our code base, this commit changes various tests to use `hg unbundle` instead of `hg pull`. This bypasses the bundlerepo code. Tests exercising exchange functionality have not been altered, as they should be using `hg pull` and going through the bundlerepo code paths. Differential Revision: https://phab.mercurial-scm.org/D3059
-
- Apr 04, 2018
-
-
Gregory Szorc authored
format.usegeneraldelta defaults to true. Differential Revision: https://phab.mercurial-scm.org/D3057
-
- Feb 21, 2018
-
-
Boris Feld authored
`hg bundle` command producing bundle2 will now include an optional part containing the revision-branch cache data. The data sent are mostly nodes so it is quite compact. The goal of the rev-branch-cache is to speed up branch map computation, especially when the branchmap gets invalidated so we send data for all exchanged changesets. In addition, computing the relevant heads to send in case of partial pulling would be challenging. As a reminder, the rev branch cache data significantly speed up branch computation. Having it around provides a small speedup to pull/clone and much higher tolerance to branch map cache invalidation that might happens from later commands. On the Mercurial repository, computing the visible branchmap from scratch move from 2.00 seconds to 0.34s (a -83% speedup). Using this new part, Unbundling the full Mercurial repository moves from 25.736 seconds to 24.030 seconds (around -7% speedup). The bundle size increase is around 3% (from 22.43 MB to 23.13MB) On an half a million revision repository with twenty thousand branches, computing the branchmap moves from 75 seconds to 45 second (-40%) if the caches is used. A bundle containing 50 000 changesets in such repository get a 0.5% size increase from such part for a -3% unbundling time speedup.
-
- Jan 18, 2018
-
-
Augie Fackler authored
# skip-blame just a bytes prefix Differential Revision: https://phab.mercurial-scm.org/D1907
-
Augie Fackler authored
# skip-blame because we're just adding b'' Differential Revision: https://phab.mercurial-scm.org/D1889
-
- Jan 15, 2018
-
-
Martin von Zweigbergk authored
This adds a transaction summary callback that reports the number of new orphan, content-divergent and phase-divergent changesets. The code for reporting it is based on the code from the evolve extension, but simplified a bit. It simply counts the numbers for each kind of instability before and after the transaction. That's obviously not very efficient, but it's easy to reason about, so I'm doing this as a first step that can make us quite confident about the test case changes. We can optimize it later and make sure that the tests are not affected. The code has been used in the evolve extension for a long time and has apparently been sufficiently fast, so it doesn't seem like a pressing issue. Unlike the evolve extension's version of this report, this version applies to all commands (or all transactions run as part of any command, to be exact). Differential Revision: https://phab.mercurial-scm.org/D1867
-
- Dec 22, 2017
-
-
Anton Shestakov authored
-