Skip to content
Snippets Groups Projects
  1. Sep 17, 2018
  2. Sep 20, 2018
  3. Sep 18, 2018
  4. Sep 20, 2018
    • Martin von Zweigbergk's avatar
      fastannotate: process files as they arrive · d8a7690c
      Martin von Zweigbergk authored
      peer.commandexecutor()'s context manager waits for all responses to
      arrive in its __exit__() method. We want to process the results as
      they arrive, so we should do that inside the context manager
      scope. Note that the futures' result() methods have been replaced to
      make sure that the command executor's sendcommands() method is called
      when the first future's result is requested, so we don't need to do
      that.
      
      A minor side-effect is that we can no longer easily tell when the
      server has started sending us responses, so that long statement was
      lost.
      
      Differential Revision: https://phab.mercurial-scm.org/D4666
      d8a7690c
  5. Sep 19, 2018
  6. May 22, 2018
    • Sean Farley's avatar
      memctx: simplify _manifest with new revlog nodeids · a5dafefc
      Sean Farley authored
      This was originally written before we had modifiednodeid and
      addednodeid, so we had to get the parents of the context, the data from
      the function, and then hash that.
      
      This is much more simple now and helps refactor more code later.
      a5dafefc
    • Sean Farley's avatar
      context: remove unused overlayfilectx (API) · 15e86ecf
      Sean Farley authored
      It seems that this was maybe used in an extension but at this point
      nothing in lfs, hg-experimental, or any other cursory repo looked at has
      a reference to this class; so, for now, let's just remove it.
      15e86ecf
  7. Jun 12, 2018
  8. Jul 18, 2018
    • Sean Farley's avatar
      filectx: fix return of renamed · 7375a9ab
      Sean Farley authored
      How is this not blowing up everywhere?
      
      It seems that filelog.renamed has always returned False (incorrectly a
      boolean) instead of the assumed None. Tracing through history, you need
      to skip over my move of code in 2013 by annotating from 896193a9cab4^
      and you can see the original code is from 2007 (180a3eee4b75) and that
      ab9fa7a85dd9 broke this by assuming renamed was a bool (instead of
      None).
      
      Refactoring memctx code later exposed this bug.
      7375a9ab
  9. Sep 19, 2018
  10. Sep 03, 2018
  11. Sep 02, 2018
  12. Sep 12, 2018
    • Gregory Szorc's avatar
      localrepo: extract resolving of opener options to standalone functions · b10d1458
      Gregory Szorc authored
      Requirements and config options are converted into a dict which is
      available to the store vfs to consult. This is how storage options
      are communicated from the repo layer to the storage layer.
      
      Currently, we do that option resolution in a private method on the
      repo instance. And there is a single method doing that resolution.
      
      Opener options are logically specific to the storage backend they
      apply to. And, opener options may wish to influence how the repo
      object/type is constructed. So it makes sense to have more granular
      storage option resolution that occurs before the repo object is
      instantiated.
      
      This commit extracts the code for resolving opener options into new
      module-level functions. These functions are run before the repo
      instance is constructed.
      
      As part of the code move, we split the option resolution into
      generic and revlog-specific options. After this commit, we no longer
      add revlog-specific options to repos that don't have a revlog
      requirement.
      
      Some of these opener options and associated config options might make
      sense on alternate storage backends. We can always reuse config
      options and opener option names for other backends. But we shouldn't
      be passing opener options to storage backends that won't recognize
      them. I haven't done it here, but after this commit it should be
      possible for store backends to validate the set of opener options
      it receives.
      
      Because localrepository.openerreqs is no longer used after this commit,
      it has been removed.
      
      I'm not super thrilled about the code outside of localrepo that is
      adding requirements and updating opener options. We'll probably want
      to create a more formal API for that use case that constructs a new
      repo instance and poisons the old repo object. But this was a
      pre-existing issue and can be dealt with later. I have little doubt
      it will cause me troubles as I continue to refactor how repository
      objects are instantiated.
      
      .. api::
      
         ``localrepository.openerreqs`` has been removed. Override
         ``localrepo.resolvestorevfsoptions()`` to add custom opener options.
      
      .. api::
      
         ``localrepository._applyopenerreqs()`` has been removed. Use
         ``localrepo.resolvestorevfsoptions()`` to add custom opener options.
      
      Differential Revision: https://phab.mercurial-scm.org/D4576
      b10d1458
    • Gregory Szorc's avatar
      localrepo: use boolean in opener options · 6f26417b
      Gregory Szorc authored
      Not sure why we're using an integer for a flag value here. I'm
      pretty sure nothing relies on values being 1.
      
      While we're here, convert to a dict comprehension.
      
      Differential Revision: https://phab.mercurial-scm.org/D4575
      6f26417b
    • Gregory Szorc's avatar
      localrepo: move store() from store module · f4418760
      Gregory Szorc authored
      I want logic related to requirements handling to be in the localrepo
      module so it is all in one place.
      
      I would have loved to inline this logic. Unfortunately, statichttprepo
      also calls it. I didn't want to inline it twice. We could potentially
      refactor statichttppeer. But meh.
      
      Differential Revision: https://phab.mercurial-scm.org/D4574
      f4418760
    • Gregory Szorc's avatar
      localrepo: resolve store and cachevfs in makelocalrepository() · 98ca9078
      Gregory Szorc authored
      This is mostly a code move and refactor.
      
      One change is that we now explicitly look for requirements indicating
      a share is being used rather than blindly try to read from
      .hg/sharedpath. Requirements *should* be all that is necessary to
      dictate high-level behavior and I'm not sure why the previous code
      was doing what it was.
      
      The previous code has been in place since 87d1fd40f57e (authored in
      2009). And the commit immediately after that (971e38a9344b) introduced
      ``hg.share()`` and always wrote the ``shared`` requirement. And as far
      as I can tell, every revision of ``hg.share()`` since has written
      either the ``shared`` or ``relshared`` requirement. So I'm pretty
      sure we don't need to maintain BC by always looking for and honoring
      the ``.hg/sharedpath`` file even if a requirement isn't present.
      
      .. bc::
      
         A repository will no longer use shared storage if it has a
         ``.hg/sharedpath`` file but no entry in ``.hg/requires`` saying it
         is shared.
      
         This change should not have any end-user impact, as all shared
         repos should have a ``.hg/requires`` file indicating this.
      
      Differential Revision: https://phab.mercurial-scm.org/D4573
      98ca9078
    • Gregory Szorc's avatar
      localrepo: document and test bug around opening shared repos · 9de1a1c8
      Gregory Szorc authored
      As part of refactoring this code, I realized that we don't
      validate the requirements of a shared repository. This commit
      documents that next to the requirements validation code and adds a
      test demonstrating the buggy behavior.
      
      I'm not sure if I'll fix this. But it is definitely a bug that
      users could encounter, as LFS, narrow, and potentially other
      extensions dynamically add requirements on first use. One part
      of this I'm not sure about is how to handle loading the .hg/hgrc
      of the shared repo. We need to do that in order to load extensions.
      But we don't want that repo's hgrc to overwrite the current repo's.
      
      Differential Revision: https://phab.mercurial-scm.org/D4572
      9de1a1c8
    • Gregory Szorc's avatar
      localrepo: move requirements reasonability testing to own function · cb2dcfa5
      Gregory Szorc authored
      Just because we know how to handle each listed requirement doesn't
      mean that set of requirements is reasonable.
      
      This commit introduces an extension-wrappable function to validate
      that a set of requirements makes sense.
      
      We could combine this with ensurerequirementsrecognized(). But I think
      having a line between basic membership testing and compatibility
      checking is more powerful as it will help differentiate between
      missing support and buggy behavior.
      
      Differential Revision: https://phab.mercurial-scm.org/D4571
      cb2dcfa5
    • Gregory Szorc's avatar
      statichttprepo: use new functions for requirements validation · 61929805
      Gregory Szorc authored
      The new code in localrepo for requirements gathering and validation
      is more robust than scmutil.readrequires(). Let's port statichttprepo
      to it.
      
      Since scmutil.readrequires() is no longer used, it has been removed.
      
      It is possible extensions were monkeypatching this to supplement the
      set of supported requirements. But the proper way to do that is to
      register a featuresetupfuncs. I'm comfortable forcing the API break
      because featuresetupfuncs is more robust and has been supported for
      a while.
      
      .. api::
      
         ``scmutil.readrequires()`` has been removed.
      
         Use ``localrepo.featuresetupfuncs`` to register new repository
         requirements.
      
         Use ``localrepo.ensurerequirementsrecognized()`` to validate them.
      
      Differential Revision: https://phab.mercurial-scm.org/D4570
      61929805
    • Gregory Szorc's avatar
      localrepo: validate supported requirements in makelocalrepository() · 5b8e9b20
      Gregory Szorc authored
      This should be a glorified code move. I did take the opportunity to
      refactor things. We now have a separate function for gathering
      requirements and one for validating them.
      
      I also mode cosmetic changes to the code, such as not using
      abbreviations and using a set instead of list to model missing
      requirements.
      
      Differential Revision: https://phab.mercurial-scm.org/D4569
      5b8e9b20
    • Gregory Szorc's avatar
      localrepo: read requirements file in makelocalrepository() · 6a3162ed
      Gregory Szorc authored
      Previously, scmutil.readrequires() loaded the requirements file
      and validated its content against what was supported.
      
      Requirements translate to repository features and are critical to
      our plans to dynamically create local repository types. So, we must
      load them in makelocalrepository() before a repository instance is
      constructed.
      
      This commit moves the reading of the .hg/requires file to
      makelocalrepository(). Because scmutil.readrequires() was performing
      I/O and validation, we inlined the validation into
      localrepository.__init__ and removed scmutil.readrequires().
      
      I plan to remove scmutil.readrequires() in a future commit (we can't
      do it now because statichttprepo uses it).
      
      Differential Revision: https://phab.mercurial-scm.org/D4568
      6a3162ed
    • Gregory Szorc's avatar
      localrepo: check for .hg/ directory in makelocalrepository() · 2f067e36
      Gregory Szorc authored
      As part of this, we move the check to before .hg/hgrc is loaded,
      as it makes sense to check for the directory before attempting to
      open a file in it.
      
      Differential Revision: https://phab.mercurial-scm.org/D4567
      2f067e36
    • Gregory Szorc's avatar
      localrepo: load extensions in makelocalrepository() · e0c50171
      Gregory Szorc authored
      Behavior does change subtly.
      
      First, we now load the hgrc before optionally setting up the vfs ward.
      That's fine: the vfs ward is for debugging and we know we won't hit it
      when reading .hg/hgrc. If the loaded extension were performing repo/vfs
      I/O, then we'd be worried. But extensions don't have access to the
      repo object that loaded them when they are loaded. Unless they are
      doing stack walking as part of module loading (which would be crazy),
      they shouldn't have access to the repo that incurred their load.
      
      Second, we now load extensions outside of the try..except IOError
      block. Previously, if loading an extension raised IOError, it would
      be silently ignored. I'm pretty sure the IOError is there for missing
      .hgrc files and should never have been ignored for issues loading
      extensions. I don't think this matters in reality because extension
      loading traps I/O errors.
      
      Differential Revision: https://phab.mercurial-scm.org/D4566
      e0c50171
    • Gregory Szorc's avatar
      localrepo: copy ui in makelocalrepository() · f19bba3f
      Gregory Szorc authored
      We will want to load the .hg/hgrc file from makelocalrepository() so
      we can consult its options as part of deriving the repository type.
      
      This means we need to create our ui instance copy in that function.
      
      Differential Revision: https://phab.mercurial-scm.org/D4565
      f19bba3f
    • Gregory Szorc's avatar
      localrepo: move some vfs initialization out of __init__ · 2f9cdb5b
      Gregory Szorc authored
      In order to make repository types more dynamic, we'll need to move the
      logic for determining repository behavior out of
      localrepository.__init__ so we can influence behavior before the type
      is instantiated.
      
      This commit starts that process by moving working directory and .hg/
      vfs initialization to our new standalone function for instantiating
      local repositories.
      
      Aside from API changes, behavior should be fully backwards compatible.
      
      .. api::
      
         localrepository.__init__ now does less work and accepts new args
      
         Use ``hg.repository()``, ``localrepo.instance()``, or
         ``localrepo.makelocalrepository()`` to obtain a new local repository
         instance instead of calling the ``localrepository`` constructor
         directly.
      
      Differential Revision: https://phab.mercurial-scm.org/D4564
      2f9cdb5b
    • Gregory Szorc's avatar
      localrepo: create new function for instantiating a local repo object · bfeab472
      Gregory Szorc authored
      Today, there is a single local repository class - localrepository. Its
      __init__ is responsible for loading the .hg/requires file and taking
      different actions depending on what is present.
      
      In addition, extensions may define a "reposetup" function that
      monkeypatches constructed repository instances, often by implementing
      a derived type and changing the __class__ of the repo instance.
      
      Work around alternate storage backends and partial clone has made it
      clear to me that shoehorning all this logic into __init__ and operating
      on an existing instance is too convoluted. For example, localrepository
      assumes revlog storage and swapping in non-revlog storage requires
      overriding e.g. file() to return something that isn't a revlog. I've
      authored various patches that either:
      
      a) teach various methods (like file()) about different states and
         taking the appropriate code path at run-time
      b) create methods/attributes/callables used for instantiating things
         and populating these in __init__
      
      "a" incurs run-time performance penalties and makes code more
      complicated since various functions have a bunch of "if storage is X"
      branches.
      
      "b" makes localrepository quickly explode in complexity.
      
      My plan for tackling this problem is to make the local repository type
      more dynamic. Instead of a static localrepository class/type that
      supports all of the local repository configurations (revlogs vs other,
      revlogs with ellipsis, revlog v1 versus revlog v2, etc), we'll
      dynamically construct a type providing the implementations that are
      needed for the repository on disk, derived from the .hg/requires file
      and configuration options. The constructed repository type will be
      specialized and methods won't need to be taught about different
      implementations nor overloaded.
      
      We may also leverage this functionality for building types that don't
      implement all attributes. For example, the "intents" feature allows
      commands to declare that they are read only. By dynamically
      constructing a repository type, we could return a repository instance
      with no attributes related to mutating the repository. This could
      include things like a "changelog" property implementation that doesn't
      check whether it needs to invalidate the hidden revisions set on every
      access.
      
      This commit establishes a function for building a local repository
      instance. Future commits will start moving functionality from
      localrepository.__init__ to this function. Then we'll start dynamically
      changing the returned type depending on options that are present.
      
      This change may seem radical. But it should be fully compatible with
      the reposetup() model - at least for now.
      
      Differential Revision: https://phab.mercurial-scm.org/D4563
      bfeab472
  13. Sep 17, 2018
    • Gregory Szorc's avatar
      transaction: make entries a private attribute (API) · 3d22aef3
      Gregory Szorc authored
      This attribute is tracking changes to append-only files. It is
      an implementation detail and should not be exposed as part of
      the public interface.
      
      But code in repair was accessing it, so it seemingly does belong
      as part of the public API. But that code in repair is making
      assumptions about how storage works and is grossly wrong when
      alternate storage backends are in play. We'll need some kind of
      "strip" API at the storage layer that knows how to handle things
      in a storage-agnostic manner. I don't think accessing a private
      attribute on the transaction is any worse than what this code
      is already doing. So I'm fine with violating the abstraction for
      transactions.
      
      And with this change, all per-instance attributes on transaction
      have been made private except for "changes" and "hookargs." Both
      are used by multiple consumers and look like they need to be
      part of the public interface.
      
      .. api::
      
         Various attributes of ``transaction.transaction`` are now ``_``
         prefixed to indicate they shouldn't be used by external
         consumers.
      
      Differential Revision: https://phab.mercurial-scm.org/D4634
      3d22aef3
    • Gregory Szorc's avatar
      transaction: make names a private attribute · 4024c363
      Gregory Szorc authored
      This is used to report the transaction name in __repr__. It is
      very obviously an implementation detail and doesn't need to be
      exposed as part of the public interface. So mark it as private.
      
      Differential Revision: https://phab.mercurial-scm.org/D4633
      4024c363
    • Gregory Szorc's avatar
      transaction: make map a private attribute · 1a68c9b1
      Gregory Szorc authored
      This is used to track which files are modified. It is an
      implementation detail of current transactions and doesn't need
      to be exposed to the public interface. So mark it as private.
      
      Differential Revision: https://phab.mercurial-scm.org/D4632
      1a68c9b1
    • Gregory Szorc's avatar
      transaction: make report a private attribute · 337d6e0f
      Gregory Szorc authored
      This is a callable used for logging. It isn't used outside the
      transaction code. It doesn't need to be part of the public interface.
      Let's mark it as private.
      
      Differential Revision: https://phab.mercurial-scm.org/D4631
      337d6e0f
    • Gregory Szorc's avatar
      transaction: make opener a private attribute · b590f476
      Gregory Szorc authored
      The VFS instance is an implementation detail of the transaction
      and doesn't belong as part of the public interface. So mark it as
      private.
      
      Differential Revision: https://phab.mercurial-scm.org/D4630
      b590f476
Loading