There will be about 1h of downtime on 2020-03-02 at 13:00 UTC+1 (change of servers and upgrade to Heptapod 0.20.0 final)

  1. 19 Nov, 2020 6 commits
  2. 17 Nov, 2020 1 commit
    • Georges Racinet's avatar
      branch: filtering obsolete heads · 5360f8ad1c10
      Georges Racinet authored
      Same thing that our current hg-git conversion does, *but* this
      is known to have performance issues on large repositories. Putting
      this on a call path that the client has every right to think is cheap
      is very problematic.
      I would prefer a simple rule that Heptapod never exposes any obsolete
      head in its branch queries. The rationale for that would be that
      by definition Git does not either present any unreachable commit.
      For the time being (Heptapod 0.17), the projects backed by HGitaly are
      highly experimental, so we can probably live with it.
  3. 18 Nov, 2020 2 commits
    • Georges Racinet's avatar
      GitLab default branch: using an empty default when not set yet · 3a01705daacd
      Georges Racinet authored
      As the comment explains, this is for now the only way to let
      the Rails app actually know that the default branch hasn't been
      set yet.
      After a lot of defaultings in the applicative code, this eventually
      activates the code that's responsible for actually setting it while
      receiving the first push.
      We can do something much more robust and maintainable, but that
      will be after the first push. Meanwhile, we do have functional
      tests about that to cover our backs.
    • Georges Racinet's avatar
      branch: don't let bookmarks shadow the default GitLab branch · b9889983cb68
      Georges Racinet authored
      We introduce a flag in the inner function that sorts out what
      to do of the branchmap entries, and use it for the default GitLab
      branch only.
      As the test demonstrates, the default GitLab branch will still
      point to the latest bookmarked head, which is consistent with
      what happens with "wild" multiple heads.
      This is a minor change of behaviour compared to the Heptapod
      standard, in which the default GitLab branch would not move in
      that case. The reason is that we don't have a natural support to
      store the previous position of the default GitLab branch.
      Of course hg-git based repositories have/had this extra state, in
      the form of the actual Git branch. The new behaviour is not worse
      and as much arbitrary as the previous one, and will of course
      be matched by py-heptapod's mirrorring to Git.
  4. 17 Nov, 2020 7 commits
    • Georges Racinet's avatar
      revision: GitLab branches given in full ref form · 9abda71b6de9
      Georges Racinet authored
      In many cases, the client will send revision specification
      also in ref form, e.g, `refs/heads/branch/default`. We
      were already resolving branch names and tags, now we have to
      support this, too.
      We should do something similar about tags
    • Georges Racinet's avatar
      Commit: lookup methods have to work with obsolete · 71abb99104b7
      Georges Racinet authored
      The Rails app will store some changeset IDs and get back to HGitaly
      for information after a while. For instance, this is what happens
      with Merge Requests. It's perfectly possible that the changeset has
      become obsolete in the mean time.
      Hence the right thing to do is to make these commit methods work
      on the unfiltered repository.
      In order to mutualize, we're actually making the
      `gitlab_revision_changeset` return also obsolete changesets if
      queried by exact hash. This is consistent with the Git case: a
      ref should never be obsolete, but an exact lookup can return
      unreferenced commits.
      In the tests, it was about time for the `make_empty_repo` helper
      to activate the evolve extension. Thankfully no other test is
      affected (without evolve, `amend` would strip the previous changeset)
    • Georges Racinet's avatar
      Commit: supporting pseudo-range notation (two dots) · 74f9767bef94
      Georges Racinet authored
      We will probably have to factorize this for reuse in
      FindCommits and the like. We'll see.
    • Georges Racinet's avatar
      Commit: proper not_found in CommitIsAncestor · 0e78099a98da
      Georges Racinet authored
      This one was in the way of the current goal: getting the
      functional tests to pass.
    • Georges Racinet's avatar
      Ref: proper not_found in FindBranch · d3f79d7565bb
      Georges Racinet authored
      Again one on the path to get functional tests pass.
    • Georges Racinet's avatar
      Commit: proper not_found in CommitsBetween · cde272dcf5c8
      Georges Racinet authored
      This also brings the coverage up to 100% by actually testing
      the `not_found()` helper.
    • Georges Racinet's avatar
      errors: helper for NOT_FOUND · d66a1b4cb3e3
      Georges Racinet authored
      As said in the docstring, we don't gain that much, especially
      with the caller probably needing a multi-line statement.
      Still it's a bit less painful to use, and good for uniformity.
  5. 15 Nov, 2020 1 commit
  6. 10 Nov, 2020 3 commits
    • Georges Racinet's avatar
      Added tag 0.2.0 for changeset 30788b68d15b · f1a2babb7510
      Georges Racinet authored
    • Georges Racinet's avatar
      Setting version for release · 30788b68d15b
      Georges Racinet authored
    • Georges Racinet's avatar
      Repository loading: returning proper error if not found · 66a4803f0f22
      Georges Racinet authored
      We already had good enough error responses for the case when
      the *storage* is not found, but it was missing for the case
      when the repository is not found in an existing storage.
      This is important, because it can actually break the landing page
      of some users: the Rails application does not seem to expect an
      unspecified Gitaly error here, but it should recover from
      I've been impaired by this on dev setup after
      with some repository removals, but don't have anything of that
      kind on hand any more, which would be more reassuring.
      We could have a better separation in concerns, as the
      subsequent change in `RepositoryExists()` indicates, but that's
      not a blocker for the imminent release.
  7. 09 Nov, 2020 5 commits
  8. 31 Oct, 2020 1 commit
  9. 01 Nov, 2020 3 commits
  10. 28 Oct, 2020 1 commit
  11. 16 Oct, 2020 1 commit
    • Georges Racinet's avatar
      Heptapod CI: using the new base CI images · 37d21a0e709c
      Georges Racinet authored
      This raises the question of homegeneity of branch naming conventions
      between py-heptapod and HGitaly (see long comment, with reference to
      There was also a glitch while installing py-heptapod. The solution
      adopted is a path of least resistance.
  12. 15 Oct, 2020 5 commits
  13. 13 Oct, 2020 2 commits
    • Georges Racinet's avatar
      GetArchive: honouring the path parameter · fd5edb7b17e6
      Georges Racinet authored
      In the GitLab application, this is used for download
      links in "subtrees" of the repository.
      An archival metadata file is not expected (nor is it on
      the Git side).
      I've checked that `git archive` behaves similarly, i.e., just
      an inclusion rule, with no re-anchoring of the files at the top
      of the archive.
    • Georges Racinet's avatar
      path: validation utilities · 3be51d8ba0ad
      Georges Racinet authored
      We'll need to perform the same kind of validation on paths
      that Gitaly does, and Mercurial itself already provides us
      with utilities to re-expose.
  14. 12 Oct, 2020 1 commit
  15. 13 Oct, 2020 1 commit
    • Georges Racinet's avatar
      Streaming utilities, starting with WRITE_BUFFER_SIZE · 510895fa5f79
      Georges Racinet authored
      Gitaly centralizes the sizes of chunks for streaming
      of binary large objects, with default values and
      tuning possibilities from environment. We are doing the
      same here.
      First use case will be repository archive production.