Skip to content
Snippets Groups Projects
  1. Dec 02, 2020
  2. Dec 15, 2020
  3. Dec 14, 2020
  4. Dec 13, 2020
  5. Dec 06, 2020
  6. Dec 14, 2020
  7. Dec 06, 2020
    • Georges Racinet's avatar
      server: handling SIGTERM, propagating to worker processes · 5a14152b5ac0
      Georges Racinet authored
      While it sounds like a good idea to to register the handler even
      before the workers started, this actually has them inheriting
      it and mask the one installed by Mercurial. So currently,
      we theoretically still have a race: if the main process gets
      a SIGTERM before registration, there could already be some
      workers, to which it wouldn't be propagated.
      5a14152b5ac0
    • Georges Racinet's avatar
      Server: avoid useless workers if only Unix Domain sockets · 609a4238a682
      Georges Racinet authored
      Reminder: we can't yet do multiprocessing for Unix Domain sockets.
      The startup code had already only the first worker listen to them.
      But it's fairly common that there are no addition tcp URLs to bind
      to, and in that case it's useless (and perhaps even a source of
      trouble) to start more workers.
      609a4238a682
  8. Dec 08, 2020
  9. Dec 06, 2020
  10. Dec 04, 2020
  11. Dec 03, 2020
  12. Nov 26, 2020
  13. Nov 25, 2020
    • 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
      0.4.0
      265ab7067c03
  14. Nov 22, 2020
  15. Nov 20, 2020
  16. Nov 22, 2020
  17. Nov 20, 2020
  18. Nov 19, 2020
  19. Nov 17, 2020
    • 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
  20. Nov 18, 2020
    • 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
  21. Nov 17, 2020
    • 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
Loading