1. 26 Nov, 2020 3 commits
  2. 25 Nov, 2020 6 commits
    • Georges Racinet's avatar
      multiprocessing: taking number of workers from config · 4e13d41b4262
      Georges Racinet authored
      With the `hgitaly.workers` config knob it's possible to
      specify it.
      
      If not specified, the default value is the one computed
      in `hgitaly.server`, i.e. upper rounding of half the number
      of CPUs (as seen by Python `multiprocessing`).
      4e13d41b4262
    • Georges Racinet's avatar
      server: multiprocessing (TCP only) · c5616da63f9a
      Georges Racinet authored
      See #2
      
      This works for TCP sockets only and is essentially adapted
      from the standard multiprocessing example in the `grpc`
      package: pre-binding with `SO_REUSEPORT` and not
      starting the servers before forking.
      
      We're adding some logic to keep Unix Domain Socket
      mono-processed, because we can't support them in the
      same way (SO_REUSEPORT and associated kernel balancing
      is for IP sockets only).
      
      It looks like Unix Domain Socket support would be quite
      different, and probably would involve cooperation with
      upstream grpc code for server bind.
      c5616da63f9a
    • Georges Racinet's avatar
      server: default port logic · 8dc601804ca6
      Georges Racinet authored
      We're using as default the same port that is the default if no
      `--listen` option is passed.
      8dc601804ca6
    • Georges Racinet's avatar
      A simple example client · e749a96d2c11
      Georges Racinet authored
      This can already be used for some direct testing (e.g starting
      several clients to test server multiprocessing), and is
      generally meant as something the user will want to modify.
      e749a96d2c11
    • Sushil Khanchi's avatar
      Added tag 0.4.0 for changeset 265ab7067c03 · 9494328bfb53
      Sushil Khanchi authored
      9494328bfb53
    • Georges Racinet's avatar
      Setting version for release · 265ab7067c03
      Georges Racinet authored
      265ab7067c03
  3. 22 Nov, 2020 1 commit
  4. 20 Nov, 2020 1 commit
  5. 22 Nov, 2020 1 commit
  6. 20 Nov, 2020 1 commit
  7. 19 Nov, 2020 6 commits
  8. 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.
      5360f8ad1c10
  9. 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.
      3a01705daacd
    • 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.
      b9889983cb68
  10. 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
      9abda71b6de9
    • 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)
      71abb99104b7
    • 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.
      74f9767bef94
    • 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.
      0e78099a98da
    • Georges Racinet's avatar
      Ref: proper not_found in FindBranch · d3f79d7565bb
      Georges Racinet authored
      Again one on the path to get functional tests pass.
      d3f79d7565bb
    • 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.
      cde272dcf5c8
    • 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.
      d66a1b4cb3e3
  11. 15 Nov, 2020 1 commit
  12. 10 Nov, 2020 3 commits
    • Georges Racinet's avatar
      Added tag 0.2.0 for changeset 30788b68d15b · f1a2babb7510
      Georges Racinet authored
      f1a2babb7510
    • Georges Racinet's avatar
      Setting version for release · 30788b68d15b
      Georges Racinet authored
      30788b68d15b
    • 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
      NOT_FOUND.
      
      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.
      66a4803f0f22
  13. 09 Nov, 2020 5 commits
  14. 31 Oct, 2020 1 commit
  15. 01 Nov, 2020 1 commit