- Feb 22, 2025
-
-
Pierre-Yves David authored
Same rational as the parent changeset.
-
- Oct 26, 2024
-
-
Pierre-Yves David authored
The traceback changes again with 3.13. So we filter it to only keeps the bits we care about. This is actually only reusing the approach from a few line below.
-
- Oct 29, 2023
-
-
Georges Racinet authored
The list of flags supported by the Rust index is not dynamic, hence flagprocessor has no chance to work.
-
- 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.
-
- Jan 04, 2023
-
-
Matt Harbison authored
Presumably these were paired with `(no-py3 !)` at one point, but now they were unconditionally true. test-check-code.t required a couple of `(glob)` markers on the changed lines in test-lfs-serve-access.t, because of the `$LOCALIP` usage on those lines. Not sure how those lines slipped through the checks previously.
-
- Feb 20, 2022
-
-
Gregory Szorc authored
I simply did a search for `^.* \(no-py3 !\)\n` and removed all matched lines. There are still some references to no-py3. But these were the simpler ones to match against. Differential Revision: https://phab.mercurial-scm.org/D12253
-
- Aug 18, 2021
-
-
Pierre-Yves David authored
The file path in the traceback become module name. Differential Revision: https://phab.mercurial-scm.org/D11294
-
- 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 28, 2020
-
-
Pierre-Yves David authored
The lines moved around because of 89a2afe31e82. Differential Revision: https://phab.mercurial-scm.org/D9447
-
- 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
-
- Jan 18, 2020
-
-
Gregory Szorc authored
For reasons I don't understand, Python 3.8 is outputting a different lint in the traceback than prior Pythons. The lines in question are: flagutil.addflagprocessor( REVIDX_NOOP, (noopdonothingread, noopdonothing, validatehash,) ) Python <3.8 prints the 2nd line but 3.8 the first line. Perhaps Python changed its traceback logic to always print the first line of a multiple line expression? Whatever the case, with this change, the test now passes on Python 3.8. Differential Revision: https://phab.mercurial-scm.org/D7945
-
- Nov 04, 2019
-
-
Denis Laxalde authored
This improves the rendering of some exceptions by avoiding raw bytestrings, especially when using --traceback option.
-
- Oct 06, 2019
-
-
Augie Fackler authored
This is using my patch to black (https://github.com/psf/black/pull/826) so we don't un-wrap collection literals. Done with: hg files 'set:**.py - mercurial/thirdparty/** - "contrib/python-zstandard/**"' | xargs black -S # skip-blame mass-reformatting only # no-check-commit reformats foo_bar functions Differential Revision: https://phab.mercurial-scm.org/D6971
-
- Aug 07, 2019
-
-
Pierre-Yves David authored
-
Pierre-Yves David authored
-
Pierre-Yves David authored
This module is meant to host most of the flag processing logic. We start with the mapping between flag and processors.
-
- Feb 02, 2019
-
-
Gregory Szorc authored
The exception is being generated from ui.traceback(), which simply calls traceback.format_*() to format exceptions. Since the output from the standard library has changed, there is seemingly not much we can do about it. So this commit adds conditional output depending on the Python version. I'm not thrilled about b'' appearing in user-facing output. Can we do something better here? Differential Revision: https://phab.mercurial-scm.org/D5806
-
- Oct 10, 2018
-
-
Matt Harbison authored
This allows flag processors to be registered to specific repos in an extension by wrapping localrepo.resolverevlogstorevfsoptions(). I wanted to add the processors via a function on localrepo, but some of the places where the processors are globally registered don't have a repository available. This makes targeting specific repos in the wrapper awkward, but still manageable.
-
- Apr 05, 2018
-
-
Gregory Szorc authored
There were a couple of bugs around the implementation of flags processing with the simple store. After these changes, test-flagprocessor.t now passes! test-flagprocessor.t was also updated to include explicit test coverage that pushed data is as expected on the server. The test extension used by test-flagprocessor.t has been updated so it monkeypatches the object returned from repo.file() instead of monkeypatching filelog.filelog. This allows it to work with extensions that return custom types from repo.file(). The monkeypatching is rather hacky and probably is performance prohibitive for real repos. We should probably come up with a better mechanism for registering flag processors so monkeypatching isn't needed. Differential Revision: https://phab.mercurial-scm.org/D3116
-
- Dec 11, 2017
-
-
Matt Harbison authored
# skip-blame because this was mechanically rewritten the following script. I ran it on both *.t and *.py, but none of the *.py changes were proper. All *.t ones appear to be, and they run without addition failures on both Windows and Linux. import argparse import os import re ap = argparse.ArgumentParser() ap.add_argument('path', nargs='+') opts = ap.parse_args() globre = re.compile(r'^(.*) \(glob\)(.*)$') for p in opts.path: tmp = p + '.tmp' with open(p, 'rb') as src, open(tmp, 'wb') as dst: for line in src: m = globre.match(line) if not m or '$LOCALIP' in line or '*' in line: dst.write(line) continue if '?' in line[:-3] or ('?' in line[:-3] and line[-3:] != '(?)'): dst.write(line) continue dst.write(m.group(1) + m.group(2) + '\n') os.unlink(p) os.rename(tmp, p)
-
- Oct 17, 2017
-
-
Martin von Zweigbergk authored
I have spent a lot of time debugging extensions that failed to load because we don't include a traceback and I didn't realize I could get traceback for the extension failure with --traceback. Let's just turn them on by default, since it should be rare that the user sees these tracebacks anyway (and if they do, it's not so bad if the extra traceback pushes them a little harder to report the problem). Since we already had a test case with --traceback and one without, I just removed the one with the flag. Differential Revision: https://phab.mercurial-scm.org/D1164
-
- 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.
-
- Jul 31, 2017
-
-
Martin von Zweigbergk authored
Differential Revision: https://phab.mercurial-scm.org/D204
-
Martin von Zweigbergk authored
The test for duplicate flag processors depended on the timestamps being set in the dirstate to work. If the time between the the previous failed commit (which would set the timestamp, due to bug 5645) and the attempted commit with the duplicate flag processors was small enough, it would fail. The failure was caused by a call to commands.status() early in the commit process. If the dirstate did not have the timestamp set, it would need to fetch the file content to compare with. Since two flag processors had been registered, it would attempted to base64 decode the contents twice, which would of course fail. This patch adds a "hg debugrebuilddirstate" to make it deterministic and also replaces the test case's "hg commit" by simply "hg status", since that will trigger reading of the contents and thereby use of the flag processors as noted above. Differential Revision: https://phab.mercurial-scm.org/D202
-
Martin von Zweigbergk authored
The flag processors test for duplicate processors for a single flag was misleading because the file from the previous test case caused it to fail (making the "echo 'this should fail' > file" part irrelevant). Let's remove the leftover from the previous test case to make it clear that duplicate flag processors results only in a warning. Note that duplicate flag processors would have resulted in a failure (not just a warning) until ea1c2eb7abd3 (extensions: catch uisetup and extsetup failures and don't let them break hg, 2017-06-06). I remember expressing my concern about ending up with half-loaded extensions. It would be pretty unfortunate to have double-encoded revlog content enter a repo, so maybe we should reconsider? Differential Revision: https://phab.mercurial-scm.org/D201
-
- Jun 06, 2017
-
-
Augie Fackler authored
Otherwise users of the patience diff extension will be unable to run anything at all in hg 4.3 until they figure out what's broken.
-
- Apr 09, 2017
-
-
Jun Wu authored
Previously, revlog.size equals to revlog.rawsize. However, the flag processor framework could make a difference - "size" could mean the length of len(revision(raw=False)), while "rawsize" means len(revision(raw=True)). This patch makes it so. This corrects "hg status" output when flag processor is involved. The call stack looks like: basectx.status -> workingctx._buildstatus -> workingctx._dirstatestatus -> workingctx._checklookup -> filectx.cmp -> filelog.cmp -> filelog.size -> revlog.size
-
- Apr 07, 2017
- Apr 03, 2017
-
-
Jun Wu authored
This is similar to "revlog: use raw revisions in revdiff". revdiff() generates raw text used in revlog directly. This makes test-flagprocessor.t happy.
-
- Apr 07, 2017
-
-
Jun Wu authored
Similar to fixes in revlog.py, this patch uses "rawtext" to explicitly label contents expected to be raw, and makes sure content stored in _cache is raw text. Now test-flagprocessor.t points us to another issue.
-
Jun Wu authored
This fixes bundlerevlog.flags(rev) for any revisions provided by the bundle. Now test-flagprocessor.t points us to another issue.
-
Jun Wu authored
"baserevision" returns the text that will be used to apply deltas. Since deltas are against raw texts, "baserevision" should return raw text. Now test-flagprocessor.t points us to a new error.
-
Jun Wu authored
This shows flag processor is broken with a bundle repo. The test creates non-liner history to exercise code path where the deltaparent cannot be reused.
-
- Jan 10, 2017
-
-
Remi Chaintron authored
Add the ability for revlog objects to process revision flags and apply registered transforms on read/write operations. This patch introduces: - the 'revlog._processflags()' method that looks at revision flags and applies flag processors registered on them. Due to the need to handle non-commutative operations, flag transforms are applied in stable order but the order in which the transforms are applied is reversed between read and write operations. - the 'addflagprocessor()' method allowing to register processors on flags. Flag processors are defined as a 3-tuple of (read, write, raw) functions to be applied depending on the operation being performed. - an update on 'revlog.addrevision()' behavior. The current flagprocessor design relies on extensions to wrap around 'addrevision()' to set flags on revision data, and on the flagprocessor to perform the actual transformation of its contents. In the lfs case, this means we need to process flags before we meet the 2GB size check, leading to performing some operations before it happens: - if flags are set on the revision data, we assume some extensions might be modifying the contents using the flag processor next, and we compute the node for the original revision data (still allowing extension to override the node by wrapping around 'addrevision()'). - we then invoke the flag processor to apply registered transforms (in lfs's case, drastically reducing the size of large blobs). - finally, we proceed with the 2GB size check. Note: In the case a cachedelta is passed to 'addrevision()' and we detect the flag processor modified the revision data, we chose to trust the flag processor and drop the cachedelta.
-