- Feb 22, 2025
-
-
Pierre-Yves David authored
Same rational as the parent changeset.
-
- Jul 10, 2023
-
-
Pierre-Yves David authored
This is as valid and simpler, it will help us to eventually get ride of `safehasattr`.
-
- 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.
-
- May 02, 2022
-
-
Raphaël Gomès authored
The dirstate already is capable of verifying its integrity (although v2 features are not yet checked), let's run that code in `hg verify`.
-
- Oct 19, 2022
-
-
Matt Harbison authored
I had trouble isolating some LFS blob corruption detected by `hg verify` because the traceback referenced a file, but with the `data/` prefix in the `.hg/store` path, so it couldn't be located with the `file()` revset: ``` Traceback (most recent call last): File "/mnt/d/mercurial/mercurial/revlog.py", line 3209, in verifyintegrity _verify_revision(self, skipflags, state, node) File "/mnt/d/mercurial/hgext/lfs/wrapper.py", line 246, in _verify_revision orig(rl, skipflags, state, node) File "/mnt/d/mercurial/mercurial/revlog.py", line 158, in _verify_revision rl.revision(node) File "/mnt/d/mercurial/mercurial/revlog.py", line 1816, in revision return self._revisiondata(nodeorrev, _df) File "/mnt/d/mercurial/mercurial/revlog.py", line 1870, in _revisiondata self.checkhash(text, node, rev=rev) File "/mnt/d/mercurial/mercurial/revlog.py", line 1996, in checkhash % (self.display_id, pycompat.bytestr(revornode)) mercurial.error.RevlogError: integrity check failed on data/EXE/PPC/shrinksrec.exe:0 ``` (I'm a little surprised it resulted in a stacktrace instead of just a message, but that's a different issue. I'm also not sure how to trigger the simplestore case, since IIUC, it's also a revlog based store.) It's not clear how to handle the changelog and manifest (because the user doesn't interact with them as a file), so those cases are left alone. The other thing that would be nice to improve somehow is to indicate that the ":0" is a revlog revision, not the changeset revision that users are used to. I'm not sure how to handle the "or node" part though.
-
- Jan 07, 2022
-
-
Pierre-Yves David authored
With `share-safe`, the requirements are stored in multiple files so it seems better to use the command that retrieve the information wherever it is. Differential Revision: https://phab.mercurial-scm.org/D11985
-
- Nov 29, 2021
-
-
Pierre-Yves David authored
This make it easier to understand the message when the extensions name is common. Differential Revision: https://phab.mercurial-scm.org/D11821
-
- May 03, 2021
-
-
Pierre-Yves David authored
Differential Revision: https://phab.mercurial-scm.org/D10586
-
- 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
-
- Nov 17, 2020
-
-
Martin von Zweigbergk authored
Now that `ParseError`s raised while reading the config file has been converted into `ConfigError`s, the remaining parse errors should all be "input errors" (i.e. exit code 10), according to https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan. Differential Revision: https://phab.mercurial-scm.org/D9332
-
- Nov 20, 2020
-
-
Martin von Zweigbergk authored
This replaces two raises of `ParseError` by `ConfigError`, which makes it so we get the desired exit code when `ui.detailed-exit-code` is enabled. Because the exceptions include a location, I had to add that to `ConfigError` as well. I considered making `ConfigError` a subclass of `ParseError`, but it doesn't feel like it quite passes the "is-a" test. I used "config error: " as prefix for these errors instead of the previous "hg: parse error: ", which seems a little less accurate now (and, as I've said before, I don't know what the "hg: " part is supposed to signify anyway). I can easily be convinced to change the prefix to something else (including "abort: "). Some of the exceptions raised here mean that we fail to even load the `ui` object in the `dispatch` module. When that happens, we don't know to use detailed exit codes, so some tests (e.g. `test-hgrc.t`) still see exit code 255. I'll try to get back to that later. It should be possible to give detailed exit codes if at least part of the config can be read (e.g. when the system-wide one enables detailed exit codes and the user's config fails to parse). Differential Revision: https://phab.mercurial-scm.org/D9355
-
- Jul 06, 2020
-
-
Manuel Jacob authored
On Python 3, pycompat.{stdin,stdout,stderr} are usually block-buffered even if connected to a TTY. procutil.{stdin,stdout,stderr} provide consistent behavior across platforms and Python versions.
-
- Jan 18, 2020
-
-
Gregory Szorc authored
The print was inserting b'' on Python 3. In addition, since we weren't writing to the ui instance (which isn't readily available in this function), output order could get mixed up. We add some pycompat casts and a stdout flush to make the test happy on all Python versions. Differential Revision: https://phab.mercurial-scm.org/D7938
-
- Dec 23, 2019
-
-
Matt Harbison authored
This applies the new marker in the lfs handler to show it in action, and adds the test mentioned at the beginning of the series to show that fulltext isn't necessary in the LFS case. The existing `skipread` isn't enough, because it is also set if an error occurs reading the revlog data, or the data is censored. It could probably be cleared, but then it technically violates the interface contract. That wouldn't matter for the existing verify algorithm, but it isn't clear how that will change as alternate storage support is added. The flag is probably pretty revlog specific, given the comments in verify.py. But there's already filelog specific stuff in there and I'm not sure what future storage will bring, so I don't want to over-engineer this. Likewise, I'm not sure that we want the verify method for each storage type to completely drive the bus when it comes to detecting renames, so I don't want to go down the rabbithole of having verifyintegrity() return metadata hints at this point. Differential Revision: https://phab.mercurial-scm.org/D7713
-
Matt Harbison authored
The `skipflags` config was introduced in a2ab9ebcd85b, which specifically calls out downloading and storing all blobs as potentially too expensive. But I don't see any reason to skip blobs that are already available locally. Hashing the blob is the only way to indirectly verify the rawdata content stored in the revlog. (The note in that commit about skipping renamed is still correct, but the reason given about needing fulltext isn't.) Differential Revision: https://phab.mercurial-scm.org/D7712
-
- Dec 20, 2019
-
-
Matt Harbison authored
Trying to validate the fulltext of an external revision causes missing blobs to be downloaded and cached. Since the downloads aren't batch prefetched[1] and aren't compressed, this can be expensive both in terms of time and space. I made this a tri-state instead of a simple bool because there's an existing (undocumented) config to handle this, and it would be weird if `hg verify` were to suddenly start ignoring that config but an `hg recover` initiated verify honors it. Since this uses the same config setting, it too will skip rename verification (which requires fulltext, but not for LFS). [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-April/116118.html Differential Revision: https://phab.mercurial-scm.org/D7708
-
- 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
-
- 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.
-
- Aug 07, 2019
-
-
Pierre-Yves David authored
We update callers incrementally because this help bisecting failures. This was useful during development, so we expect it might be useful again in the future.
-
- Oct 19, 2018
-
-
Matt Harbison authored
This is in the spirit of bcf72d7b1524.
-
- Oct 02, 2018
-
-
Matt Harbison authored
I missed these in 803b7569c9ea because I forgot about `...` lines.
-
Matt Harbison authored
-
Matt Harbison authored
This is needed to keep py3 happy. The other two instances of sorting already did this.
-
- Sep 24, 2018
-
-
Gregory Szorc authored
This method is no longer used by external consumers. The API is quite low-level and is effectively len(revision(raw=True)). I don't see a compelling reason to keep it around. Let's drop the API and make the file storage interface simpler. Differential Revision: https://phab.mercurial-scm.org/D4750
-
- Sep 21, 2018
-
-
Gregory Szorc authored
LFS is monkeypatching filelog.filelog and is then accessing various filelog attributes in the monkeypatched function. This is all fine. But some of the attributes being accessed by LFS are revlog centric and shouldn't be exposed on the file storage interface. This commit changes the monkeypatched functions to access proxied attributes on self._revlog instead of self. This should be safe to do because non-revlog repositories should not be using filelog instances: instead they should have a separate class to represent file storage. So it is reasonable for LFS to assume the _revlog attribute exists and points to a revlog. Differential Revision: https://phab.mercurial-scm.org/D4714
-
- Sep 20, 2018
-
-
Gregory Szorc authored
Now that repository loading in core supports automatically loading the lfs extension when the "lfs" requirement is present, we no longer need to update the .hg/hgrc of newly-created repos to load the lfs extension! I'm marking this as BC because it is a change in behavior. But users should not notice unless they create an LFS repo with new Mercurial and then attempt to use it with an old versions that doesn't support automatic extension loading. Differential Revision: https://phab.mercurial-scm.org/D4712
-
Gregory Szorc authored
If an unrecognized requirement is present (possibly due to an unloaded extension), the user will get an error message telling them to go to https://mercurial-scm.org/wiki/MissingRequirement for more info. And some requirements clearly map to known extensions shipped by Mercurial. This commit teaches repository loading to automatically map requirements to extensions. We implement support for loading the lfs extension when the "lfs" requirement is present. This behavior feels more user-friendly to me and I'm having trouble coming up with a compelling reason to not do it. The strongest argument I have against is that - strictly speaking - requirements are general repository features and there could be N providers of that feature. e.g. in the case of LFS, there could be another extension implementing LFS support. And the user would want to use this non-official extension rather than the built-in one. The way this patch implements things, the non-official extension could be missing and Mercurial would load the official lfs extension, leading to unexpected behavior. But this feels like a highly marginal use case to me and doesn't outweigh the user benefit of "it just works." If someone really wanted to e.g. use a custom LFS extension, they could prevent the built-in one from being loaded by either defining "extensions.lfs=/path/to/custom/extension" or "extensions.lfs=!", as the automatic extension loading only occurs if there is no config entry for that extension. Differential Revision: https://phab.mercurial-scm.org/D4711
-
- Sep 19, 2018
-
-
Matt Harbison authored
Python3 defaults to installing under "Program Files".
-
- 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
-
- Jun 09, 2018
-
-
Yuya Nishihara authored
This makes fileset expression open to any input, so that we can just say "hg status 'set: not binary()'" to select text files including unknowns. With this and removal of subset computation, 'set:**' becomes as fast as 'glob:**'. Further optimization will probably be possible by narrowing the file tree to compute status for example. This also fixes 'subrepo()' to not ignore the current mctx.subset. .. bc:: The fileset expression may include untracked files by default. Use ``tracked()`` to explicitly filter out files not existing at the context revision.
-
- Jun 21, 2018
-
-
Matt Harbison authored
This ensures that the blobs don't need to be present to be filtered properly.
-
Matt Harbison authored
Since LFS stores the binary attribute in the pointer file, this means that the file doesn't need to be downloaded in order to be skipped. This function also catches an IOError if the data can't be loaded in the non-LFS case. I wonder if it's worth storing the unix/dos attributes in the pointer file as well, though I'd expect LFS files to be binary most of the time.
-
- May 15, 2018
-
-
Kyle Lippincott authored
As far as I can tell, most of these failures are due to using $HGPORT, which it seems chg might be using itself? I don't know enough to debug these failures to fix them properly. Differential Revision: https://phab.mercurial-scm.org/D3562
-
- Apr 06, 2018
-
-
Gregory Szorc authored
rawsize() is not reimplemented outside of revlog. I'm not sure why this code was insisting it call a specific implementation. Changing it to call rawsize() on the repo.file(f) result seems to work just fine. Differential Revision: https://phab.mercurial-scm.org/D3153
-
- Apr 03, 2018
-
-
Gregory Szorc authored
Getting these tests to pass is more work than it is worth right now. Let's punt on it. Differential Revision: https://phab.mercurial-scm.org/D3063
-
- 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 07, 2018
-
-
Jun Wu authored
There is no way to distinguish whether a delta base is LFS or non-LFS. If the delta is against LFS rawtext, and the client trying to apply it has the base revision stored as fulltext, the delta (aka. bundle) will fail to apply. This patch forbids using delta for LFS revisions in changegroup so bad deltas won't be transmitted. Note: this does not solve the problem entirely. It solves LFS delta applying to non-LFS base. But the other direction: non-LFS delta applying to LFS base is not solved yet. Differential Revision: https://phab.mercurial-scm.org/D2067
-
- Mar 03, 2018
-
-
Augie Fackler authored
Somehow these are only caught when running the test under Python 3. Differential Revision: https://phab.mercurial-scm.org/D2580
-
- Jan 28, 2018
-
-
Matt Harbison authored
The callstatus setting is required to notice the removal of 'lfs.test' in rev 6 in the tests, even though this isn't directly calling mctx.status(). However, it's not needed to get the results in the tests for `hg status`, so I'm probably missing something.
-