Skip to content
Snippets Groups Projects
  1. Feb 26, 2024
  2. Feb 13, 2024
  3. Feb 12, 2024
  4. Feb 06, 2024
    • Georges Racinet's avatar
      DiffService.GetPatchId: initial implementation · 972fd9a8b2cc
      Georges Racinet authored
      Since `git patch-id` does not involve the repository at all (it
      ingests a patch and outputs a hash), we are actually spawning it,
      with a Mercurial generated patch.
      
      For general consistency (and hoping it does not matter so much),
      we are computing the index lines as for the `RawDiff` method, but
      Git seems to actually ignore it.
      
      We are avoiding to extract the full content of binary files, as it
      would be expensive and essentially useless. This is also what Gitaly
      does, and we probably should generalize it to some other `DiffService`
      methods (to be checked)
      
      As the Comparison Tests display, the patch id computed by HGitaly
      turns out to be identical to the done by Gitaly for simple text-only
      diffs. That will obviously not be true of binary diffs.
      972fd9a8b2cc
  5. Feb 11, 2024
  6. Feb 10, 2024
  7. Feb 09, 2024
  8. Jan 29, 2024
  9. Jan 28, 2024
    • Georges Racinet's avatar
      MercurialOperations: define and implement MergeBranch · dca77baea98a
      Georges Racinet authored
      This is the counterpart of Gitaly's `OperationService.UserMergeBranch`.
      
      We had to make a dedicated method because
      
      - the two-phase system of Gitaly does not make sense for Mercurial:
        merging does move branches right away, as branch information is
        enclosed in the changeset. We started development by mimicking it,
        but it soon became overly complicated
      - we have the `semi_linear` field, nothing alike on the Gitaly side,
        since the method always performs a merge, and ours would fast-forward
        by default.
      - we have error cases that do not exist in Git (obsolescence and
        instability checks). Actually, we reuse some of Gitaly errors
        to ease the burden of treatment on the client side. The case
        of `reference_check` being a borderline, but it shouldn't matter
        much.
      
      (bumping minimal py-heptapod version for `GitRepo.git()` helper method)
      dca77baea98a
  10. Jan 29, 2024
  11. Jan 28, 2024
  12. Jan 23, 2024
    • Georges Racinet's avatar
      Comparison tests: separated method to compare exceptions · 794bbdd4c2fb
      Georges Racinet authored
      As explained in the docstring, this will allow comparing exceptions
      obtained with different gRPC methods. First use-case will be Mercurial
      version of `UserMergeBranch` that will have to differ yet will return
      same exceptions and structured errors.
      
      Also introducing a way normalize structured errors: some of them, such
      as `MergeConflictError` can indeed contain commit ids.
      794bbdd4c2fb
    • Georges Racinet's avatar
      Servicer: adopted changeset publication method · d4c14b0b88f6
      Georges Racinet authored
      Because of the duality bewteen `OperationService` and
      `MercurialOperationService`, it will be useful to have it upstairs in the
      class hierarchy (attributes are really used, to that moving to an
      utility module will not be appropriate)
      d4c14b0b88f6
  13. Jan 18, 2024
    • Georges Racinet's avatar
      MercurialRepositoryService, proto: defined `ResetCaches` method. · 10aeb6d5502a
      Georges Racinet authored
      It is meant to back `hg_reset_tags_cache`, but we make room for
      other caches that could be useful in the future.
      10aeb6d5502a
    • Georges Racinet's avatar
    • Georges Racinet's avatar
      MercurialRepositoryService: added `Recover` and `Optimize` methods · 98e6b1627f81
      Georges Racinet authored
      The request and response for `Recover` were already defined, but the
      method was not.
      98e6b1627f81
    • Georges Racinet's avatar
      MercurialRepository proto: new Pull method · c143dda0c0c8
      Georges Racinet authored
      No need for user and internal API dance, so that is simple.
      We assume that the list of Gitlab branches will be small enough,
      but we could make a streaming variant later on if needed.
      Similarly, upstream's `FetchRemote` is not streaming either.
      c143dda0c0c8
    • Georges Racinet's avatar
      MercurialOperationService: implement PublishChangeset with GitLab hooks errors · a0aee70be565
      Georges Racinet authored
      The pre- and post-receive hooks error treatment is an important aspect
      of the question, since we cannot really test it from the service tests
      (we should at some point start a fake internal API server to that
      effect).
      However, the uniformity introduced by the `errors.operation_error_treatment`
      context manager makes it acceptable for the time being. First, it is
      entirely unit-tested, preventing stupid mistakes common in untested
      error treatment and second, this mutualization has the effect of having
      each gRPC method test its siblings, e.g., testing a real-life authorization
      failure would test all of them. It still depends on absence of typos
      in the protocol (would be better to make the `gitlab_hook` attribute name
      used in all of our methods).
      
      Since this method will soon be used on the Rails side for the
      file operations only, we don't add all checks that are in `UserFFBranch`
      for obsolete and unstable changesets, but we could.
      a0aee70be565
Loading