Skip to content
Snippets Groups Projects
  1. Sep 05, 2022
  2. Jun 05, 2021
  3. May 31, 2021
    • Georges Racinet's avatar
      WIP Repository instance cache: using in HTTP serving · 1e90d92f0aa7
      Georges Racinet authored
      This is enough to launch functional tests and more generally
      experiment on development instances, but must not come near a
      production server, as it is essentially an infinitely growing
      cache.
      1e90d92f0aa7
    • Georges Racinet's avatar
      Repository instance caching: instantiation and retrieval · e6cb016900fb
      Georges Racinet authored
      This is the main cache logic, based on the previously
      introduced "mutation id" primitives.
      
      clear_repo_classes() and its usage in the instance reclaim
      hook are taken from heptapod.wsgi, where they have been
      introduced to avoid a memory leak.
      e6cb016900fb
    • Georges Racinet's avatar
      testhelpers: wrap commits in a store lock · e46383e6962a
      Georges Racinet authored
      Since we're about to introduce a repository instance cache,
      whose invalidation will be tied on store lock acquire/release,
      it is necessary for all tests that will use this cache (HGitaly
      gRPC tests notably) that operations from the test helpers also
      acquire the lock.
      
      As the comment says, this should actually have been the default,
      but we need to exert some caution and we need it right away.
      e46383e6962a
    • Georges Racinet's avatar
      Repository instance caching: setting mutation id on lock release · e67327a55a37
      Georges Racinet authored
      Closes #10
      
      All writes to the repository store should be protected by
      `repo.lock()`. This change makes it so that a new mutation id,
      as previously introduced gets written upon lock release.
      
      This is enough for a caching mechanism to perform invalidations
      e67327a55a37
    • Georges Racinet's avatar
      Repository instance caching: mutation id primitives · e0c4b2db17a1
      Georges Racinet authored
      This introduces a new file in the Mercurial store, whose
      purpose will be to change at each mutation of the store
      contents, so that a cache invalidation logic can be based
      on its value.
      e0c4b2db17a1
  4. Jun 20, 2022
  5. Jun 12, 2022
  6. May 31, 2022
  7. May 16, 2022
  8. Apr 05, 2022
  9. Mar 14, 2022
  10. Feb 05, 2022
    • Georges Racinet's avatar
      Stop post-processing branchmap entries for obsolescence · c78aee1fe363
      Georges Racinet authored
      With the Mercurial 6.1 (core see heptapod#633) taking obsolescence
      into account while updating branchmap, it is no longer necessary
      to perform the (very slow) post-processing provided by the evolve
      extension.
      
      Because of the big jump in minimum required Mercurial version,
      we make it a major version change.
      
      Fixing heptapod#632 will thus boil down to requiring
      py-heptapod>=4.0.0dev0
      
      This post-processing was the standard if evolve is activated
      (through the single heads enforcement logic),
      but the heptapod extension was (and still is) disabling it because
      it needs to call it itself anyway.
      See 834eb9379d73 for details.
      c78aee1fe363
  11. Feb 26, 2022
  12. Jan 25, 2022
  13. Jan 23, 2022
  14. Jan 03, 2022
  15. Jan 02, 2022
  16. Nov 26, 2021
  17. Nov 15, 2021
Loading