- 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.
-
Matt Harbison authored
-
- Jan 27, 2018
-
-
Matt Harbison authored
This currently has the same limitation as {lfs_files}, namely it doesn't report removed files. We may want a dedicated 'lfs()' revset for efficiency, but combining this with the 'contains()' revset should be equivalent for now. Combining with 'set:added()' or 'set:modified()' inside 'files()' should be equivalent to a hypothetical lfs_adds() and lfs_modifies(). I wonder if there's a way to tweak the filesets to evaluate lazily, to close the efficiency gap. It would also be interesting to come up with a template filter for '{files}' that looked at the pattern to 'files()', and filtered appropriately. While passing a fileset as the pattern to `hg log` does filter '{files}', the set is evaluated against the working directory, so there's no way to list all non-lfs files above a certain size in all revisions, for example.
-
- Feb 04, 2018
-
-
Matt Harbison authored
In addition to merge, this method ultimately gets called by many commands: - backout - bisect - clone - fetch - graft - import (without --bypass) - pull -u - rebase - strip - share - transplant - unbundle - update Additionally, it's also called by histedit, shelve, unshelve, and split, but it seems that the related blobs should always be available locally for these. For `hg update`, it happens after the normal argument checking and pre-update hook processing, and remote corruption is detected prior to manipulating the working directory. Other commands could use this treatment (archive, cat, revert, etc), but this covers so many of the frequently used bulk commands, it seems like a good starting point. Losing the verbose message that prints the file name before a corrupt blob aborts the command is a little sad, because there's no easy way to go from oid to file name. I'd like to change that message to list the file name so it looks cleaner and less cryptic, but the pointer object is nowhere near where it needs to be to do this. So punt on that for now.
-
- Jan 30, 2018
-
-
Matt Harbison authored
The .hgignore file doesn't need to be tracked, nor does the git equivalent of this file. I'm still a little concerned about the effects of forgetting to commit this file. But the fact that conversions maintain the hashes if only the normal vs external storage changes, should make this less risky.
-
- Jan 25, 2018
-
-
Matt Harbison authored
This was useful in debugging, because I stupidly quoted it out of habit from the command line. This isn't a great example that clearly shows the problem, but I don't know how to improve it. The problem *is* obvious once a complex statement or a clearly bogus string is used.
-
- Jan 24, 2018
-
-
Matt Harbison authored
The only reasons I did this in the first place was because tracking externally seems like it would always be a mistake, and the eol extension does the same thing. Yuya and Jun thought it might be better to not do this[1], so I'll defer to them on this. If a problem with say, .hgtags or .hgeol does arise, it can be added back without breaking existing repos. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-January/110371.html
-
Matt Harbison authored
Per Yuya, for consistency with {lfspointer}. It might be slightly confusing for there to be {lfsoid} and {lfspointer.oid}. But preventing ambiguity seems more important, and the latter is controlled by the git-lfs spec.
-
- Jan 22, 2018
-
-
Matt Harbison authored
Per Martin von Zweigbergk's suggestion to keep this unambiguous, for when it is migrated to {files} and friends.
-
- Jan 20, 2018
-
-
Matt Harbison authored
This seems more descriptive.
-