Skip to content
Snippets Groups Projects
  1. Feb 22, 2025
  2. Oct 26, 2024
  3. Oct 29, 2023
  4. Jun 26, 2023
  5. Jan 04, 2023
    • Matt Harbison's avatar
      tests: drop `(py3 !)` output matching predicates · 950c39918bd2
      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.
      950c39918bd2
  6. Feb 20, 2022
  7. Aug 18, 2021
  8. Dec 10, 2020
  9. Nov 28, 2020
  10. Nov 23, 2020
  11. Jan 18, 2020
    • Gregory Szorc's avatar
      py3: conditionalize test-flagprocessor.t on Python 3.8 · 35cd52c4a5cc
      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
      35cd52c4a5cc
  12. Nov 04, 2019
  13. Oct 06, 2019
  14. Aug 07, 2019
  15. Feb 02, 2019
    • Gregory Szorc's avatar
      py3: add Python 3 output for test-flagprocessor.t · 3e9c6cef949b
      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
      3e9c6cef949b
  16. Oct 10, 2018
    • Matt Harbison's avatar
      revlog: allow flag processors to be applied via store options · 9d5ddf55415b
      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.
      9d5ddf55415b
  17. Apr 05, 2018
    • Gregory Szorc's avatar
      simplestore: correctly implement flag processors · 9d4f09bfe3ec
      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
      9d4f09bfe3ec
  18. Dec 11, 2017
    • Matt Harbison's avatar
      tests: remove (glob) annotations that were only for '\' matches · 4441705b7111
      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)
      4441705b7111
  19. Oct 17, 2017
    • Martin von Zweigbergk's avatar
      extensions: always include traceback when extension setup fails · 78d9a7b7cdb6
      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
      78d9a7b7cdb6
  20. Oct 12, 2017
    • Denis Laxalde's avatar
      transaction-summary: show the range of new revisions upon pull/unbundle (BC) · eb586ed5d8ce
      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.
      eb586ed5d8ce
  21. Jul 31, 2017
    • Martin von Zweigbergk's avatar
    • Martin von Zweigbergk's avatar
      tests: fix test-flagprocessor.t flakiness · c6146dd10072
      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
      c6146dd10072
    • Martin von Zweigbergk's avatar
      tests: clarify that duplicate flag processors is not an error · 41081364addb
      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
      41081364addb
  22. Jun 06, 2017
  23. Apr 09, 2017
    • Jun Wu's avatar
      revlog: make "size" diverge from "rawsize" · 0ab7f469d386
      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
      0ab7f469d386
  24. Apr 07, 2017
  25. Apr 03, 2017
    • Jun Wu's avatar
      bundlerepo: use raw revision in revdiff() · 37e793918c07
      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.
      37e793918c07
  26. Apr 07, 2017
    • Jun Wu's avatar
      bundlerepo: fix raw handling in revision() · 4598e8f43e20
      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.
      4598e8f43e20
    • Jun Wu's avatar
      bundlerepo: build revlog index with flags · 4bafc80f827e
      Jun Wu authored
      This fixes bundlerevlog.flags(rev) for any revisions provided by the bundle.
      
      Now test-flagprocessor.t points us to another issue.
      4bafc80f827e
    • Jun Wu's avatar
      bundlerepo: make baserevision return raw text · 433ab46f6bb4
      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.
      433ab46f6bb4
    • Jun Wu's avatar
      test-flagprocessor: add tests about bundlerepo · 723c1ab2f77e
      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.
      723c1ab2f77e
  27. Jan 10, 2017
    • Remi Chaintron's avatar
      revlog: flag processor · c1b7b2285522
      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.
      c1b7b2285522
Loading