Skip to content
Snippets Groups Projects
  1. Dec 12, 2020
  2. Dec 04, 2020
    • Georges Racinet's avatar
      Heptapod CI: base image tag is now `default` · 04d44016
      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.
      04d44016
    • Georges Racinet's avatar
      Heptapod CI: deriving tag of upstream image from hg branch · f8254617
      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.
      f8254617
    • Georges Racinet's avatar
      Heptapod CI: proper base image for stable, and less jobs · 7e8e6205
      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).
      7e8e6205
  3. Dec 03, 2020
    • Georges Racinet's avatar
      Start of new stable branch · 5bfeeac1
      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.
      5bfeeac1
  4. Dec 02, 2020
  5. Dec 01, 2020
    • Georges Racinet's avatar
      Git: caching read of Git(Lab) default branch · 57f18c4e
      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.
      57f18c4e
  6. Nov 30, 2020
  7. Nov 29, 2020
  8. Nov 28, 2020
    • Georges Racinet's avatar
      take over single head enforcement · 834eb937
      Georges Racinet authored
      See heptapod#351
      
      This prevents the expensive `_filter_obsolete_heads`
      to be called twice on each transaction: the first in
      evolve's `enforcesinglehead`, the second in our analysis
      code for GitLab branches.
      
      In 1.1 versions, we don't want to change the
      meaning of configuration flags, hence we still react
      to `experimental.single-head-per-branch`.
      
      In the future 1.2 versions, however, we will ignore that
      flag and base everything on `heptapod.allow-multiple-heads`,
      hence sparing us the monkey patching.
      834eb937
  9. Nov 27, 2020
  10. Nov 24, 2020
    • Georges Racinet's avatar
      dulwich: backporting fix for bytes problem in alternates · a3d8f1eb
      Georges Racinet authored
      Sub-classing Dulwich whole testcase brings in all the tests
      from that class, but we don't care: they pass in less than a
      second.
      
      Given the release rate of dulwich, a new version should be
      available soon, but we haven't tested anything from 0.20.5.
      It doesn't look like the best time to update. In any case
      the backport gives us more options.
      
      Closes heptapod#370
      a3d8f1eb
  11. Nov 23, 2020
  12. Nov 22, 2020
    • Georges Racinet's avatar
      testhelpers: shortened LocalRepoWrapper as RepoWrapper · 3026eeb6
      Georges Racinet authored
      This is of the same spirit as in mercurial-testhelpers.
      
      We keep a compatibility alias for downstream projects,
      such as HGitaly and hg-loggingmod, but we should be able to
      get rid of it soon.
      3026eeb6
    • Georges Racinet's avatar
      testhelpers: using new external package · 5708f063
      Georges Racinet authored
      These testhelpers have been externalized as the
      `mercurial_testhelpers` package.
      
      The latter being meant to be identical to a future
      `mercurial.testhelpers` in Mercurial core, they don't
      have facilities for topics nor evolve specific commands.
      
      But the commit options extensibility can be used to
      specify topics in `commit_file`. As for the `prune` helper
      method, it can be implemented by direct subclassing.
      
      This is what `hg-evolve` could later do, if that project
      were to adopt those test helpers. Downstream extensions
      of evolve and topic could then just use a base class
      provided by evolve.
      
      Also, the `RepoWrapper` from `mercurial_testhelpers` has
      two different method names, that we remap directly to
      make the whole test suite pass.
      5708f063
  13. Nov 21, 2020
  14. Nov 11, 2020
Loading