Skip to content
Snippets Groups Projects
  1. Mar 07, 2021
    • Georges Racinet's avatar
      GitLab special refs: ensuring the state file presence · 1476f1dcb8aa
      Georges Racinet authored
      This is provided as a CLI command and an easy to import
      function. The decision to ensure the state file from the
      Git repository should not belong to py-heptapod, but
      either to an operator fixing inconsistencies or to HGitaly.
      
      All currently existing refs on native Mercurial repositories
      are Merge Request heads: no other ref could have worked, because
      `WriteRef` is currently refusing to do anything else than
      setting the default branch.
      
      Still, we have the possiblity of corruption with the same TODO
      as for branches and tags.
      1476f1dcb8aa
  2. Mar 10, 2021
  3. Mar 06, 2021
    • Georges Racinet's avatar
      GitLab special refs: create/read/update/delete · 4ed6f4b4255e
      Georges Racinet authored
      Part of heptapod#431.
      
      This doesn't provide a callable to initialize the special
      refs file from the Git repository refs yet.
      
      We found it acceptable to use a single file for all these
      special refs, but we decided to exlude keep-arounds for the
      reason stated in the docstring for the `SPECIAL_REFS` constant.
      
      We've considered using local Mercurial tags, but we finally
      preferred to reuse our own logic for GitLab state files.
      Reasons:
      
      - local tags are not exposed as 1st class citizens in the
        internal API, everything is meant to add them to global
        tags for exposition in `hg tags`.
      - with local tags, we'd have to perform additional namespacing
        to prevent confusion and would still be at risk of confusion
        (or even attack by masking with a global tag?)
      - the unneeded complexity for our use case in Mercurial local
        tags is such that it took us less time to implement the whole
        write and read logic on the py-heptapod primitive, with
        complete tests than to be reasonably sure of how local tags
        really behave (cache invalidation etc.)
      - uniformity of py-heptapod/HGitaly formats.
      4ed6f4b4255e
  4. Mar 08, 2021
  5. Feb 25, 2021
  6. Feb 23, 2021
    • Georges Racinet's avatar
      Extensions: require and activate config-express · b14b26ff5180
      Georges Racinet authored
      With the given defaults settings, clients won't see any difference.
      
      hg-configexpress 0.4.0 passes all tests with Mercurial 5.6,
      the series we're using in current Heptapod.
      
      The question of how to configure selected projects is entirely open.
      For now, users have to modify the repo (or group) HGRCs on the server
      file system.
      
      Since there are auxiliary files, the question of backuping them is
      also open.
      
      Closes heptapod#190
      b14b26ff5180
  7. Feb 15, 2021
    • Georges Racinet's avatar
      Gitlab tags state file: using/ensuring in state maintainers · 8a30e3edb771
      Georges Racinet authored
      At this point, we can send the appropriate pre- and post-receive
      notifications to GitLab about tags.
      
      To help with transition, there is a utility to ensure existence
      of the state file.
      8a30e3edb771
    • Georges Racinet's avatar
      Gitlab refs state files: added tags · 8427294a95ea
      Georges Racinet authored
      At this point we have the tags state file, but
      it's not in use yet.
      8427294a95ea
    • Georges Racinet's avatar
      GitLab refs state files: genericized from branch case · 338e9895dd0a
      Georges Racinet authored
      We will have to track tags to support pre-/post-receive
      notifications to GitLab in fully native repos.
      
      We've been pondering about that a bit, as it could be simpler
      to just store all refs. In truth, we may later also have
      to store special refs such as Merge Requests and keeparounds,
      although these are bad examples because Mercurial should not
      need them.
      
      In the end the different update profiles and the fact that
      changed tags don't seem to be easily available from the
      transaction object made us go the way of two distinct
      files.
      
      The "typed ref" terminology got adopted because we've seen
      Git man pages use it. We speak of "short names" because
      usually "ref" can either mean the general concept or the
      name of a ref (for instance, branches are refs as concepts
      but branch names aren't ref names).
      
      Of course, much of the read/write/cache logic could be
      and have been factorized.
      Now it's a bit weird for it to lie in a `branch` module,
      we should rename it at some point to `ref` or `typed_ref`.
      338e9895dd0a
  8. Feb 14, 2021
  9. Feb 13, 2021
  10. Jan 29, 2021
  11. Jan 28, 2021
  12. Jan 23, 2021
  13. Jan 22, 2021
Loading