Skip to content
Snippets Groups Projects
  1. Dec 18, 2020
  2. Dec 16, 2020
    • Raphaël Gomès's avatar
      config: add option to never exchange bookmarks · bf548f18cebe
      Raphaël Gomès authored
      Some repositories (particularly Octobus's `mercurial-devel` instance) do not
      want to exchange bookmarks, ever. This change applies to all exchange mechanisms
      relevant to Heptapod but was initially motivated by the new hg pull mirrors.
      bf548f18cebe
  3. Dec 17, 2020
  4. Dec 15, 2020
    • Georges Racinet's avatar
      GitLab branches state: exposing with cache and missing marker · f48941479911
      Georges Racinet authored
      This is the bare minimum needed so that downstream users such
      as HGitaly can leverage it.
      
      The final version should probably become a property on the
      repo instance, but that will require actually more work, because
      it's not immediately clear if the standard Mercurial tooling
      applies well in this quite special case, namely:
      
      - we don't want any invalidation to occur before the explicit
        write at the end of transaction, for consistency reasons:
        the very mission of the state file is to represent the state
        at the beginning of transaction.
      - we're working under the assumption that all writes to the
        repository will update the state file. This is true, yet
        very specific to the Heptapod server environment.
      
      
      It's fine for `read_gitlab_branches` to raise `FileNotFoundException`.
      Will have to see for other exceptions though.
      f48941479911
  5. Dec 14, 2020
  6. Dec 12, 2020
    • Georges Racinet's avatar
      GitHandler: updating the GitLab branches state file · a5b46e78e810
      Georges Racinet authored
      Of course, all this back-and-forth conversion from Git SHAs
      to Hg SHAs is getting long. The goal at this point is merely
      to make it available right away to HGitaly.
      
      Later on we'll have to split the branch analysis logic, and we'll
      start having a handler for Mercurial native projects, that will
      eventually not convert to Git at all.
      a5b46e78e810
    • Georges Racinet's avatar
      State file for GitLab branches · 014d5f959fe9
      Georges Racinet authored
      As explained in the long docstring, this represents the latest
      state of branches *transmitted* to GitLab, i.e. has to be considered
      the state at beginning of transaction if there is an ongoing one (used
      precisely to deduce changes to notify GitLab about) or the current
      state if there is no ongoing transaction (read-only case).
      
      The read-only case will be useful for HGitaly right away: instead
      of doing expensive computations for each branch read, it will
      leverage this file if available.
      014d5f959fe9
    • Georges Racinet's avatar
      GitHandler tests: more assertions on notifications · 73809d346424
      Georges Racinet authored
      These were long-standing TODOs.
      73809d346424
    • Georges Racinet's avatar
      Future version will be 2.0.0 · bc840e7e7d55
      Georges Racinet authored
      The change in configuration flags for multiple heads is
      a non backwards compatible change.
      bc840e7e7d55
    • Georges Racinet's avatar
      Bookmarks: don't lift multiple heads protection · 8d755f36bf4b
      Georges Racinet authored
      Thanks to previous changes, the protection against multiple heads
      happens in `HeptapodGitHandler` instead of earlier in
      the transaction.
      
      We can thus stop lifting it when bookmarks are allowed,
      because the check now occurs once bookmarked
      heads have been taken out of the game.
      
      This is a boon for projects that track Git upstreams (like many
      components of Heptapod do, including the Rails application:
      they now can now use bookmarks to track their Git upstream
      branches and still be protected against multiple heads.
      8d755f36bf4b
    • Georges Racinet's avatar
      Test utils: expose path to required.hgrc · c38f79841e5a
      Georges Racinet authored
      Necessary to test what happens with the default configuration.
      c38f79841e5a
    • Georges Racinet's avatar
      Multiple heads: controlled by heptapod flag only. · 31b99ecfc0b4
      Georges Racinet authored
      Most users were using the core `experimental.single-head-pre-branch`
      only because Heptapod included it its "required" configuration.
      
      This is not the case any more, meaning we can let go
      of the monkeypatching introduced to avoid filtering obsolete heads
      twice.
      31b99ecfc0b4
    • Georges Racinet's avatar
      tests: no coverage needed for testing log interceptor · 94494e777bb6
      Georges Racinet authored
      whether we use it or not depends on the testing needs,
      but it's not part of the main code anyway.
      94494e777bb6
  7. Dec 04, 2020
    • Georges Racinet's avatar
      Heptapod CI: base image tag is now `default` · 04d440161bb1
      Georges Racinet authored
      This was done in the stable branch, and gives us a nice uniformity.
      The `default` tag of the base image is ready for this.
      04d440161bb1
    • Georges Racinet's avatar
      Heptapod CI: deriving tag of upstream image from hg branch · f82546177c72
      Georges Racinet authored
      This matches changes done in the base mercurial image so that its
      tag is now `default` instead of `latest`.
      
      At this point, the CI configuration of py-heptapod can be the same
      in its `stable` and `default` branches.
      f82546177c72
    • Georges Racinet's avatar
      Heptapod CI: proper base image for stable, and less jobs · 7e8e6205d1bb
      Georges Racinet authored
      We need to use the `stable` tag of the base image for the `hg-current`
      job. Indeed too bad we can't just propagate the hg branch name, maybe it's
      time to do something about (uniformity makes the stable branch mergeable
      into the default branch without fear)
      
      It doesn't make much sense to run the `hg-default` and `hg-stable`
      jobs for the stable branch of py-heptapod, which won't change Mercurial
      versions, unless hg-stable is for the same hg x.y as hg-current (currently
      not the case).
      7e8e6205d1bb
  8. Dec 03, 2020
    • Georges Racinet's avatar
      Start of new stable branch · 5bfeeac1302e
      Georges Racinet authored
      With the versioning scheme explained in heptapod#352, it
      doesn't make sense any more to have stable branches labelled after
      general Heptapod versions.
      
      With py-heptapod and semver, it's quite possible that we don't need
      to actually make default diverge from stable in some cycles. Still
      it will be convenient to have a clear reference. The alternative would
      be not to change, e.g., the HDK configuration, and then forget to update
      it once it becomes necessary.
      5bfeeac1302e
  9. Dec 02, 2020
  10. Dec 01, 2020
    • Georges Racinet's avatar
      Git: caching read of Git(Lab) default branch · 57f18c4ee1df
      Georges Racinet authored
      Part of heptapod#351
      
      Suprisingly, reading HEAD with dulwich takes 25ms, and we
      were doing that for all branch/topic combination. The penalty
      is harsh when running for repositories with hundreds
      of branch/topic combinations.
      
      Caching this gets the time to perform a push on PyPy in my dev
      setup from 45s to about 4s.
      
      We could have avoided the caching, but there are some other callers,
      why spending occasional 25ms when we can avoid it?
      
      This is the occasion to move the setting logic in a separate method,
      awaiting the later refactorings for separation of "native" case
      from hg_git case.
      57f18c4ee1df
  11. Nov 30, 2020
  12. Nov 29, 2020
Loading