Skip to content
Snippets Groups Projects
  1. Feb 22, 2025
  2. Jul 10, 2023
  3. Jun 26, 2023
  4. May 02, 2022
    • Raphaël Gomès's avatar
      verify: also check dirstate · c84844cd523a
      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`.
      c84844cd523a
  5. Oct 19, 2022
    • Matt Harbison's avatar
      revlog: use the user facing filename as the display_id for filelogs · 92892dff03f3
      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.
      92892dff03f3
  6. Jan 07, 2022
  7. Nov 29, 2021
  8. May 03, 2021
  9. Dec 10, 2020
  10. Nov 23, 2020
  11. Nov 17, 2020
  12. Nov 20, 2020
    • Martin von Zweigbergk's avatar
      errors: raise ConfigError on failure to parse config file · 9dc1351d0b5f
      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
      9dc1351d0b5f
  13. Jul 06, 2020
  14. Jan 18, 2020
  15. Dec 23, 2019
    • Matt Harbison's avatar
      verify: allow the storage to signal when renames can be tested on `skipread` · b9e174d4ed11
      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
      b9e174d4ed11
    • Matt Harbison's avatar
      lfs: don't skip locally available blobs when verifying · 1a6dd50cd0db
      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
      1a6dd50cd0db
  16. Dec 20, 2019
  17. Dec 06, 2019
  18. Sep 08, 2019
    • Pierre-Yves David's avatar
      changegroup: move message about added changes to transaction summary · d7304434390f
      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.
      d7304434390f
  19. Aug 07, 2019
  20. Oct 19, 2018
  21. Oct 02, 2018
  22. Sep 24, 2018
  23. Sep 21, 2018
    • Gregory Szorc's avatar
      lfs: access revlog directly · 62a532045e71
      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
      62a532045e71
  24. Sep 20, 2018
    • Gregory Szorc's avatar
      lfs: don't add extension to hgrc after clone or share (BC) · bcf72d7b1524
      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
      bcf72d7b1524
    • Gregory Szorc's avatar
      localrepo: automatically load lfs extension when required (BC) · 2c2fadbc9851
      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
      2c2fadbc9851
  25. Sep 19, 2018
  26. Sep 04, 2018
  27. Jun 09, 2018
    • Yuya Nishihara's avatar
      fileset: rewrite predicates to return matcher not closed to subset (API) (BC) · ff5b6fca1082
      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.
      ff5b6fca1082
  28. Jun 21, 2018
  29. May 15, 2018
  30. Apr 06, 2018
  31. Apr 03, 2018
  32. Mar 06, 2018
    • Gregory Szorc's avatar
      merge with stable · 7bf80d9d9543
      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.
      7bf80d9d9543
  33. Feb 07, 2018
    • Jun Wu's avatar
      changegroup: do not delta lfs revisions · d031609b3cb7
      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
      d031609b3cb7
  34. Mar 03, 2018
  35. Jan 28, 2018
    • Matt Harbison's avatar
      lfs: teach the 'lfs()' fileset to handle removed files · 91aac8e6604d
      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.
      91aac8e6604d
Loading