Skip to content
Snippets Groups Projects
  1. Sep 24, 2018
    • Gregory Szorc's avatar
      upgrade: use rawsize() instead of revlog index · 32d3ed30
      Gregory Szorc authored
      The revlog index is a very low-level data structure and it shouldn't
      be exposed to the storage interface - at least not in its current
      form.
      
      upgrade.py is the only consumer of the index attribute on file storage
      in the repository.
      
      This commit rewrites that final consumer to use rawsize() instead of
      going through the index. This is actually the more proper API to use,
      as rawsize() will accurately report the size of revisions which have
      a negative size in the index.
      
      Differential Revision: https://phab.mercurial-scm.org/D4719
      32d3ed30
  2. Sep 21, 2018
  3. Sep 24, 2018
    • Gregory Szorc's avatar
      upgrade: report size of backing files, not internal storage size · 8dab7c8a
      Gregory Szorc authored
      upgrade.py is the only consumer of filelog.index, which I'd like
      to eliminate from the file storage interface.
      
      This commit changes the upgrade code to report the storage size
      of files by looking at the size of the files backing its storage
      instead of looking at the index.
      
      I'm not convinced the approach in this patch will live very long
      because it is relying on low-level attributes like "opener" and
      "files," which may behave very differently on non-revlog storage.
      But the data is only used for reporting purposes and it does get
      us one step closer to eliminating "index."
      
      A side-effect of this change is we now report the size of the revlog
      index data - not just the revision data. I think this is more
      accurate.
      
      Differential Revision: https://phab.mercurial-scm.org/D4717
      8dab7c8a
  4. Sep 21, 2018
    • Gregory Szorc's avatar
      filelog: store filename directly on revlog instance · 96838b62
      Gregory Szorc authored
      This attribute is only used by LFS. It is used by one of the revlog
      flag processor functions, which gets an instance of the revlog - not
      the file storage type. So, it makes sense to store this attribute on
      the revlog instead of the filelog.
      
      With this change, I'm pretty confident that LFS is no longer directly
      accessing file storage interface members that are revlog centric. i.e.
      it gets us one step closer to eliminating revlog-centric APIs from the
      file storage interface!
      
      Differential Revision: https://phab.mercurial-scm.org/D4715
      96838b62
    • 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
  5. Sep 20, 2018
    • Gregory Szorc's avatar
      largefiles: automatically load largefiles extension when required (BC) · 823a5804
      Gregory Szorc authored
      This is very similar to what we just did for LFS but for largefiles.
      See recent commit messages for the rationale here.
      
      Differential Revision: https://phab.mercurial-scm.org/D4713
      823a5804
    • 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
  6. Sep 19, 2018
    • Gregory Szorc's avatar
      lfs: add repository feature denoting the use of LFS · 1f7b3b98
      Gregory Szorc authored
      Whether LFS is enabled seems like a useful feature to expose. This
      will also facilitate some future work around LFS feature compatibility.
      
      Differential Revision: https://phab.mercurial-scm.org/D4710
      1f7b3b98
    • Gregory Szorc's avatar
      localrepo: define "features" on repository instances (API) · d89d5bc0
      Gregory Szorc authored
      There are a handful of attributes/methods on repository instances that
      describe the behavior of the repository. Furthermore, there is
      an unbound set of repository descriptors that we may wish to expose.
      For example, an extension may wish to add a descriptor and have
      monkeypatched functions look for the presence of an attribute before
      taking actions.
      
      This commit introduces a "features" mechanism to allow repositories
      to self-advertise an arbitrary set of strings that describe repository
      behavior or capabilities.
      
      We implement basic support for advertising a few features to give an
      idea of what I want to use this for.
      
      Differential Revision: https://phab.mercurial-scm.org/D4709
      d89d5bc0
  7. Sep 20, 2018
    • Gregory Szorc's avatar
      localrepo: support writing shared file (API) · d3d4b4b5
      Gregory Szorc authored
      Now that we can create a shared repository via creation options, we
      can handle other special actions related to share at repo creation time
      as well.
      
      One of the things we do after creating a shared repository is write
      out a .hg/shared file containing the list of additional things to
      share. Of which only "bookmarks" is supported.
      
      We add a creation option to hold the set of additional items to
      share. If items are defined, we write out the .hg/shared file at
      repo creation time.
      
      As part of this, we no longer hold the repo lock when writing the
      file. I'm pretty sure we don't care about the tiny race condition
      window. I'm also pretty sure the reason we used the lock was because
      the vfs auditor on the repo instance complained otherwise. Since the
      repo creation code doesn't have an audited vfs, we don't need to
      appease it.
      
      Because we no longer need to tell the post share hook what items
      are shared, the "bookmarks" argument to that function has been
      dropped, incurring an API change.
      
      Differential Revision: https://phab.mercurial-scm.org/D4708
      d3d4b4b5
    • Gregory Szorc's avatar
      localrepo: support shared repo creation · 4ece3cdf
      Gregory Szorc authored
      Previously, hg.share() had its own logic for creating a new
      repository on the filesystem.
      
      With the recent introduction of the createopts dict for passing
      options to influence repository creation, it is now possible
      to consolidate the repo creation code for both the normal and
      shared use cases.
      
      This commit teaches the repo creation code in localrepo to
      recognize when we're creating a shared repo and to act
      appropriately.
      
      Meaningful behavior should be identical. However, there are a
      few subtle changes:
      
      * The .hg/requires file is written out in sorted order (rather
        than having share-related requirements appended at end).
      * The .hg directory is created with notindexed=True when a shared
        repo is being created.
      
      Differential Revision: https://phab.mercurial-scm.org/D4707
      4ece3cdf
  8. Sep 19, 2018
    • Gregory Szorc's avatar
      localrepo: validate directories before creating any · b504ff81
      Gregory Szorc authored
      There is no meaningful change in behavior because wdir would
      already exist in the case where we raised RepoError. But I think
      the code is easier to read if we do all validation first then
      take actions with side-effects.
      
      Differential Revision: https://phab.mercurial-scm.org/D4706
      b504ff81
    • Gregory Szorc's avatar
      localrepo: add missing join() · d3e761f9
      Gregory Szorc authored
      Differential Revision: https://phab.mercurial-scm.org/D4705
      d3e761f9
    • Gregory Szorc's avatar
      revlog: use proper version comparison during verify · e6d3d39c
      Gregory Szorc authored
      Verify appears to want to compare the changelog's revlog version
      number with the version number of filelogs and error if they are
      different. But what it was actually doing was comparing the full
      32-bit header integer, which contains 2 shorts: 1 for the revlog
      version number and 1 for feature flags.
      
      This commit tweaks the verification code so it only looks at the
      version number component of the header and emits a warning if they
      differ.
      
      The new code is more robust because it accounts for future revlog
      version numbers without them needing to be special cased.
      
      Differential Revision: https://phab.mercurial-scm.org/D4704
      e6d3d39c
    • Gregory Szorc's avatar
      filelog: stop proxying checksize() (API) · 0cb3e02e
      Gregory Szorc authored
      This was only used by verify code. And the check using it is now
      implemented as part of verifyintegrity(). The method is unused
      and is revlog-centric, which means it isn't appropriate for the file
      storage interface. So remove it.
      
      Differential Revision: https://phab.mercurial-scm.org/D4703
      0cb3e02e
    • Gregory Szorc's avatar
      filelog: remove version attribute (API) · 68282a7b
      Gregory Szorc authored
      This was only used by verify code. The check it was used for is now
      implemented as part of the verifyintegrity() implementation. The
      attribute is now unused, is revlog-specific, and isn't appropriate
      to be exposing on the file storage interface. So drop it.
      
      Differential Revision: https://phab.mercurial-scm.org/D4702
      68282a7b
    • Gregory Szorc's avatar
      verify: start to abstract file verification · 97986c9c
      Gregory Szorc authored
      Currently, the file storage interface has a handful of attributes
      that are exclusively or near-exclusively used by repo verification
      code. In order to support verification on non-revlog/alternate
      storage backends, we'll need to abstract verification so it can
      be performed in a storage-agnostic way.
      
      This commit starts that process.
      
      We establish a new verifyintegrity() method on revlogs and expose
      it to the file storage interface. Most of verify.verifier.checklog()
      has been ported to this new method.
      
      We need a way to represent verification problems. So we invent an
      interface to represent a verification problem, invent a revlog type
      to implement that interface, and use it.
      
      The arguments to verifyintegrity() will almost certainly change in
      the future, once more functionality is ported from the verify code.
      And the "revlogv1" version check is very hacky. (The code in verify
      is actually buggy because it is comparing the full 32-bit header
      integer instead of just the revlog version short. I'll likely fix
      this in a subsequent commit.)
      
      Differential Revision: https://phab.mercurial-scm.org/D4701
      97986c9c
  9. Sep 24, 2018
  10. Sep 26, 2018
  11. Sep 25, 2018
  12. Sep 26, 2018
  13. Sep 25, 2018
  14. Sep 26, 2018
  15. Sep 25, 2018
  16. Sep 23, 2018
  17. Sep 22, 2018
Loading