Skip to content
Snippets Groups Projects
  1. Nov 13, 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 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
  10. Sep 17, 2023
  11. Sep 04, 2023
  12. 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
  13. 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
  14. Sep 01, 2023
  15. Aug 30, 2023
  16. Aug 31, 2023
    • Georges Racinet's avatar
      rhgitaly::mercurial::DirIteratorWithoutFlatPaths · 74c6bbd8
      Georges Racinet authored
      This iterator will be the core engine of `CommitService.GetTreeEntries` in
      the simplest case: non-recursive without flat paths computation.
      
      The flat paths computation is not as expensive in the Mercurial case as it is
      in the Git case, because we are iterating over the entire manifest anyway (a
      later version might use a binary search to find the starting point of the
      requested directory, but all files within the directory will have to be scanned),
      but not doing it enables this simple implementation: namely we can yield top-level
      directories immediately, and hence to have at most one `TreeEntry` to yield per run
      of the loop.
      74c6bbd8
  17. Aug 30, 2023
    • Georges Racinet's avatar
      rhgitaly::util::common_subpath_split · b4465e96
      Georges Racinet authored
      This utility method finds the greatest common denominator of
      two paths, and helps using the remainder in one of them.
      
      It takes care of the various edge cases (strict equality,
      trailing slashes) and will be used several times in the
      `GetTreeEntries` implementation.
      b4465e96
    • Georges Racinet's avatar
      rhgitaly::mercurial: an iterator over a directory of a manifest · 831f85fc
      Georges Racinet authored
      This will be useful to implement the various cases of `GetTreeEntries`.
      It could also be extended to be used in `ls_path`, but that would
      require treating the special case where the given path is actually a file.
      
      Consider sending this UPSTREAM.
      831f85fc
    • Georges Racinet's avatar
      rhgitaly::streaming::stream_with_pagination · 13486a81
      Georges Racinet authored
      This generic helper in `rhgitaly::streaming` is for the case
      of streamed responses with `repeated` items, the whole stream
      being the current page. In all cases known to us, GitLab derives
      some information from the last item of the last chunk to be
      the `next_cursor`, hence we introduce a trait for the item
      to represent that, and use it in the implementation.
      
      The first use-case will be the implementation of
      `CommitService.GetTreeEntries`, but this also makes
      the likes of `RefService.FindLocalBranches` essentially trivial.
      13486a81
    • Georges Racinet's avatar
      rhgitaly::streaming::stream_chunks · d124dd52
      Georges Racinet authored
      This Rust version of Python `hgitaly.util.chunked` should be useful
      for many gRPC methods. It provide the means to distinguish the first
      response, but does not implement the pagination protocol.
      d124dd52
  18. Aug 18, 2023
  19. Aug 12, 2023
  20. Aug 09, 2023
Loading