Skip to content
Snippets Groups Projects
  1. Nov 23, 2020
  2. Nov 17, 2020
  3. Nov 20, 2020
    • Martin von Zweigbergk's avatar
      errors: raise ConfigError on failure to parse config file · 9dc1351d
      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
      9dc1351d
  4. Jul 06, 2020
  5. Jan 18, 2020
  6. Dec 23, 2019
    • Matt Harbison's avatar
      verify: allow the storage to signal when renames can be tested on `skipread` · b9e174d4
      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
      b9e174d4
    • Matt Harbison's avatar
      lfs: don't skip locally available blobs when verifying · 1a6dd50c
      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
      1a6dd50c
  7. Dec 20, 2019
  8. Dec 06, 2019
  9. Sep 08, 2019
    • Pierre-Yves David's avatar
      changegroup: move message about added changes to transaction summary · d7304434
      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.
      d7304434
  10. Aug 07, 2019
  11. Oct 19, 2018
  12. Oct 02, 2018
  13. Sep 24, 2018
  14. Sep 21, 2018
    • Gregory Szorc's avatar
      lfs: access revlog directly · 62a53204
      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
      62a53204
  15. Sep 20, 2018
    • Gregory Szorc's avatar
      lfs: don't add extension to hgrc after clone or share (BC) · bcf72d7b
      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
      bcf72d7b
    • Gregory Szorc's avatar
      localrepo: automatically load lfs extension when required (BC) · 2c2fadbc
      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
      2c2fadbc
  16. Sep 19, 2018
  17. Sep 04, 2018
  18. Jun 09, 2018
    • Yuya Nishihara's avatar
      fileset: rewrite predicates to return matcher not closed to subset (API) (BC) · ff5b6fca
      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.
      ff5b6fca
  19. Jun 21, 2018
  20. May 15, 2018
  21. Apr 06, 2018
  22. Apr 03, 2018
  23. Mar 06, 2018
    • Gregory Szorc's avatar
      merge with stable · 7bf80d9d
      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.
      7bf80d9d
  24. Feb 07, 2018
    • Jun Wu's avatar
      changegroup: do not delta lfs revisions · d031609b
      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
      d031609b
  25. Mar 03, 2018
  26. Jan 28, 2018
  27. Jan 27, 2018
    • Matt Harbison's avatar
      lfs: add a fileset for detecting lfs files · eefb5d60
      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.
      eefb5d60
  28. Feb 04, 2018
    • Matt Harbison's avatar
      lfs: prefetch lfs blobs when applying merge updates · 0b79f99f
      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.
      0b79f99f
  29. Jan 30, 2018
    • Matt Harbison's avatar
      lfs: don't require the .hglfs file to be tracked to control the policy · 4425790f
      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.
      4425790f
  30. Jan 25, 2018
  31. Jan 24, 2018
  32. Jan 22, 2018
  33. Jan 20, 2018
Loading