Skip to content
Snippets Groups Projects
  1. Nov 10, 2023
  2. Oct 14, 2023
  3. Oct 11, 2023
    • Georges Racinet's avatar
      MercurialOperationsService, with first method MergeAnalysis · e513de55
      Georges Racinet authored
      This new service will take care of all mutations, in analogy with
      Gitaly's `OperationsService`. The first method is actually an exception,
      since it does not perform any mutation, but it will make sense to have
      it beside `Merge` and `FastForwardMerge`.
      
      Normally, we should not add it in stable branches, but the default branch
      is currently tied to upstream protocol updates, hence to the release
      schedule of the Rails app, which is not released frequently due to jumps
      for upstream catch-up. It will be acceptable if clients use this only
      if certain feature flags that are `false` by default are activated.
      
      The `MergeAnalysis` method should provide everything needed by the
      Rails app for all merge operations (fast-forward or not). The
      conflicts detection is the second use case of working directories
      (after `CommitLanguages`), and the first introducing local modifications.
      e513de55
  4. Oct 13, 2023
    • Georges Racinet's avatar
      working directories: fix purging · f4b5893b
      Georges Racinet authored
      It turns out that `WorkingDirectory.command()` was always running
      `update` (!). Clearly a refactoring leftover that went unnoticed
      because we did not have explicit purge testing. Now we do, with
      a focus on interrupted merges (with or without conflicts) as this
      is needed for #155
      f4b5893b
  5. Oct 09, 2023
  6. Oct 08, 2023
  7. Oct 02, 2023
    • Georges Racinet's avatar
      ListLastCommitForTree: avoid climbing the entire changelog for each path · 830f3071
      Georges Racinet authored
      The new algorithm in `latest_changeset_for_path` was more efficient on
      average than using the `files` revset predicate on a single path, but
      it was inefficient to do it over and over for a serious amount of paths
      in `ListLastCommitsForTree`.
      
      We now climb the changelog only once, keeping track of wanted files
      and subdirectories along the way.
      
      Measurements taken on the `tests/` directory of the mercurial-devel
      repository (in seconds):
      
      revset based:     270s
      parent changeset: 426s
      this changeset:    19s
      
      Figures taken before a small
      fix on the new implementation that could have improved performance.
      
      This is still quite bad, but less catastrophic than it was, and it is
      amenable to a Rust reimplementation.
      830f3071
  8. Sep 22, 2023
    • Georges Racinet's avatar
      LastCommitForPath: simpler and more perfomant implementation · 798ac9c4
      Georges Racinet authored
      The `files` revset predicate is way too slow and answers a
      much more complicated question, as it has to follow the entire
      history of the given path.
      
      Using `linkrev` on filelogs is not appropriate, because it can point to
      any changeset that introduced this version of the file, even if not
      an ancestor of `seen_from` (deduplication). Besides, it raises thorny
      questions in case path is to be interpreted as a directory, notably
      being by definition unable to take children removals into account.
      
      The `files` field of changelog entries, on the other hand, is supposed
      to list all files touched by the corresponding changeset. This forces
      us to iterate on ancestors, and could be quite arbitrary in cases of merges
      whose both parents changed a given path, but in that case the problem itself
      is not so well-defined.
      798ac9c4
    • Georges Racinet's avatar
      CommitService.LastCommitForPath: improve testing and special cases · c7704384
      Georges Racinet authored
      There were no Gitaly Comparison tests for this method.
      Also, some special cases (e.g., empty `path`) were only
      tested indirectly by the fact that the current version of
      `ListLastCommitsForTree` uses the same internal function.
      
      As expected, this uncovers some minor bugs, such as error on
      unresolvable revision, which we fix right away
      c7704384
  9. Sep 24, 2023
  10. Sep 21, 2023
    • Georges Racinet's avatar
      RHGitaly: resynced protocol with general Gitaly protocol · 14ed2552
      Georges Racinet authored
      Parent changeset removed two messages, and previous bump of Gitaly
      protocol had some other changes that don't affect RHGitaly (or introduce new
      options that are not implemented yet), but should be applied for clarity:
      RHGitaly protocol definitions should have all messages and a subset
      of the methods.
      14ed2552
    • Georges Racinet's avatar
      Bump Gitaly protocol and remove FindAll{Tags,Branch}Names methods · 9de6c722
      Georges Racinet authored
      In Gitaly 91b69d050, these deprecated methods are finally removed.
      Of course clients such as the Rails app have been using `patterns` in
      `ListRefs` for a while, which we also demonstrate in the adapted
      `test_ref.test_tags`. These use-cases of `ListRefs` were also already
      tested.
      9de6c722
  11. Sep 20, 2023
    • Georges Racinet's avatar
      CommitService.GetTreeEntries: remove root_oid · eef65d4b
      Georges Racinet authored
      Of course this requires an update of the base image, to get a Gitaly past
      the point when `root_oid` is removed from protocol. We could run locally
      the Comparison tests with 16.0.0, which is simpler to reference than an
      exact commit, so we'll try this.
      
      The length of the first response in `test_compare_get_tree_entries_pagination`
      by Gitaly changes, perhaps because each `TreeEntry` is a bit smaller (we've long
      suspected the streaming logic was based on actual size hints), but we did not
      check that.
      
      Closes #151
      eef65d4b
    • Georges Racinet's avatar
      RefService: remove PackRefs method · 60137290
      Georges Racinet authored
      It is removed from the protocol in Gitaly v16.0, all what we were doing
      is avoiding to return an error to the sender anyway.
      60137290
    • Georges Racinet's avatar
      Merged stable branch into default · a6238b82
      Georges Racinet authored
      a6238b82
  12. Sep 19, 2023
    • Georges Racinet's avatar
      SearchFilesByContent: improving memory efficiency · e40148cc
      Georges Racinet authored
      This iterator-based approach just keeps a small window of up to 3
      lines in RAM, instead of the full list previously obtained with
      splitlines()`).
      
      It uses `collections.deque` (natively implemented), to make sure the
      window will never be reallocated. On the other hand, matching lines
      are allocated afresh, which is expected not to be a problem.
      
      At this point, further improvements should take the form of an implementation
      in RHGitaly.
      e40148cc
  13. Sep 17, 2023
  14. Sep 04, 2023
  15. Aug 31, 2023
    • Georges Racinet's avatar
      GetTreeEntries: testing and fixing some corner cases · 45749dd3
      Georges Racinet authored
      Testing the case of `limit=0` and revision unknown uncovered a
      small difference between HGitaly and Gitaly (RHGitaly was already
      compliant): HGitaly was returning a response, with an empty list
      of entries.
      
      Decided to change `chunked()` to avoid yielding an empty chunk,
      but it turned out that `RepositoryService.SearchFilesByName` was
      actually expected to yield responses with empty lists, hence we
      hade to make it optional.
      
      The check in `CommitService` to avoid empty chunks having become
      default, we had to remove it to kepp coverage.
      45749dd3
  16. Aug 30, 2023
    • Georges Racinet's avatar
      RHGitaly: implement CommitService.GetTreeEntries · 63daae2a
      Georges Racinet authored
      This builds on the previously introduced elements: iterators for the
      three cases, helpers to stream in paginated chunks and activates the
      Gitaly Comparison tests for this method.
      
      The actual call to the iterators look to be identical, but they are
      not, as monomorphisation will give us three different
      `stream_get_tree_entries_from_iterator`.
      63daae2a
    • Georges Racinet's avatar
      rhgitaly::mercurial::DirIteratorWithFlatPaths · aba79850
      Georges Racinet authored
      This is the engine behind the non-recursive case of
      `CommitService.GetTreeEntries`, if `skip_flat_paths` is `false`.
      
      Like the Python reference HGitaly implementation, we are interpreting
      the "flat path" to be the greatest common path of all entries equal or
      inside the given entry (see `hgitaly.manifest` Python module for details about
      this)
      aba79850
Loading