Skip to content
Snippets Groups Projects
  1. 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
    • Georges Racinet's avatar
      rhgitaly::mercurial::RecursiveDirIterator · 934afef8
      Georges Racinet authored
      This is the core engine for one of the three modes of
      `CommitService.GetTreeEntries`.
      934afef8
  2. 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
  3. 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
  4. Aug 18, 2023
  5. Aug 12, 2023
  6. Aug 07, 2023
  7. Jul 31, 2023
  8. Aug 07, 2023
    • Georges Racinet's avatar
      rhgitaly::oid: methods for tree handling · eb6763d7
      Georges Racinet authored
      There are for now completely identical to methods for blobs,
      but they could well become different (e.g, different disk caches or
      whatever).
      eb6763d7
    • Georges Racinet's avatar
      rhgitaly::mercurial::ls_path: listing a subset of manifest · 721ac5a4
      Georges Racinet authored
      This will be useful to implement `CommitService.TreeEntry`.
      There is plenty of room for performance improvement, notably:
      
      - the position of the first relevant entry could be found
        by binary search instead of a linear scan
      - we could try and clone less
      
      But it is possible that this would not be really needed, given
      the performance and scalability boost given by RHGitaly over
      HGitaly, before Mercurial manifests start using a more efficient
      layout, making this code obsolete.
      721ac5a4
    • Georges Racinet's avatar
      RHGitaly: allowing to stream TreeEntryResponse from BlobResponseChunk · 87b6970c
      Georges Racinet authored
      We will soon implement `CommitService.TreeEntry`, which has to
      behave like `GetBlobs` on one `RevisionPath` in case it turns out
      the path is a blob.
      87b6970c
  9. Jul 31, 2023
    • Georges Racinet's avatar
      rhgitaly::mercurial: preparation for CommitService.TreeEntry · 562c5d46
      Georges Racinet authored
      We split `lookup_blob()` in two functions, so that
      parts can be reused without reopening changelogs, manifests etc.
      Notably, the implementation of `TreeEntry` will use `read_blob`
      in case it is serving a blob and not a tree: in this case
      the manifest entry has already been found, no need to reopen and
      rescan anything.
      562c5d46
  10. Aug 06, 2023
    • Georges Racinet's avatar
      RHGitaly: bumped MSRV to 1.65 · 2acf3e5f
      Georges Racinet authored
      Rust 1.65 is currently the version generally available in GitLab
      context (upstream usage appeared recently) and it is also able
      to build tokei 12.1.2, whereas 1.61 cannot.
      
      This leads up to fix the following Clippy error (not in 1.61):
      "you are deriving `PartialEq` and can implement `Eq`".
      2acf3e5f
  11. Aug 01, 2023
  12. Jul 31, 2023
    • Georges Racinet's avatar
      RHGitaly implement HasLocalBranches · e0fbe488
      Georges Racinet authored
      This method is mostly used to check if the repository is emtpy (and
      that is in the case of Mercurial logically equivalent),
      but it's better to implement it using the GitLab branches file as it
      avoids actually opening the repository, spawning a thread for
      blocking iteration etc.
      e0fbe488
  13. Jul 29, 2023
    • Georges Racinet's avatar
      RHGitaly: implementing BlobService.GetBlobs · fd8aaff5
      Georges Racinet authored
      This finally puts together all the common logic already used in
      `GetBlob`, and we can switch on the Comparison tests (one single
      test function for both gRPC methods).
      
      Using `blocking_gitlab_revision_node_prefix` is not very elegant,
      we could probably resolve all the revisions before entering the blocking
      thread (and perhaps also avoid scanning the state files many times),
      but this is deemed not so important for the time being, compared to
      the huge efficiency boost provided to Heptapod by
      implementing this method in Rust.
      
      As is now customary, the tracing part has us create a wrapper struct
      and implement `Debug` because of the bytes in `RevisionPath`. At
      some point we'll have to come up with something more generic for this.
      fd8aaff5
    • Georges Racinet's avatar
      RHGitaly: blocking variant of revision resolution · 81cb41f4
      Georges Racinet authored
      This will be used once in a thread created by `spawn_blocking`,
      typically with the closure given to the likes of
      `repository::load_repo_and_stream`.
      
      It is a bit annoying to introduce the dependency to
      `futures::executor` for this, but we don't feel at ease
      using `tokio::runtime::Runtime.block_on`, as this is really
      meant as an entry point (looks like we'd need to create a new
      runtime and it's not clear whether it would interfere with the
      current running one or not).
      81cb41f4
    • Georges Racinet's avatar
      RHGitaly: BlobService.GetBlob · 03355820
      Georges Racinet authored
      This builds on the previously introduced repository file
      extraction and conversion to `GetBlobResponse`.
      
      It is important to emit at least one response, even if the
      resulting data is empty (usually because of `limit=0`).
      03355820
    • Georges Racinet's avatar
      RHGitaly: Blob gRPC messages definitions and adapters · d274bd92
      Georges Racinet authored
      This handles the fact that `GetBlobResponse` and `GetBlobsResponse` have
      some similar logic (including metadata only on the first message for a
      given blob) and some differences (more metadata in the latter).
      
      We enclose the common logic in the new `message::BlobResponseChunk` trait,
      and implement it for both response types.
      
      The intermixing with data is not very natural in the Rust ownership
      context, we try and make it not too painful. There is possibly room
      for improvement in reducing cloning/allocations, perhaps using the
      `Bytes`-oriented variant of `prost`.
      d274bd92
    • Georges Racinet's avatar
      RHGitaly: repository files extraction with metadata · 76f69a84
      Georges Racinet authored
      This provides the base logic to access file data, and a common
      representation for metadata that will be enough to implement
      the `GetBlob` and `GetBlobs` gRPC request, and that we hope to be
      reusable for the likes of `TreeEntry` and `GetTreeEntries`.
      
      The `rhgitaly::message` module will provide the necessary conversions
      to actual Gitaly response types.
      76f69a84
    • Georges Racinet's avatar
      RHGitaly WRITE_BUFFER_SIZE lazy static · 93c0c47c
      Georges Racinet authored
      Same as in `hgitaly.streaming`, and ultimately as in Gitaly,
      this is used as a constant that can be overridden by environment
      variable.
      93c0c47c
    • Georges Racinet's avatar
  14. Jul 28, 2023
  15. Jul 25, 2023
  16. Jul 29, 2023
  17. Jul 08, 2023
    • Georges Racinet's avatar
      Merged stable branch into default · 49074aa6
      Georges Racinet authored
      Developments on stable branch were entirely driven by RHGitaly,
      leading to better matching of Gitaly in corner cases and errors.
      
      A change had to be made for Comparison tests to pass:
      the error message in `FindCommit` with no arguments at all is now
      the one about the `repository` argument missing instead of `revision`.
      This is so much a corner case that we don't bother matching and
      simply add `same_details=False`. The change may have happened anywhere
      between Gitaly v15.5 and v15.9.
      49074aa6
  18. Jul 05, 2023
  19. Jun 29, 2023
    • Georges Racinet's avatar
      RHGitaly: CommitService.FindCommit implementation · 6e654158
      Georges Racinet authored
      This is now a direct application of `gitlab_revision_node_prefix()`.
      Perhaps worth of notice is the fact thay we stay purely async until
      the revision is resolved as a `NodePrefix`, and only spawn a thread
      once it is really needed (access to repository `Changelog`).
      6e654158
    • Georges Racinet's avatar
      RHGitaly: message::commit_for_node_prefix · 6b54aa74
      Georges Racinet authored
      This method is fairly simple, but it has the tremendous advantage
      to flatten three possible `RevlogError` into one, considerably
      simplifying error treatment for the caller.
      6b54aa74
    • Georges Racinet's avatar
      RHGitaly: repository loading helper for unary RPC methods · 8b6fdf35
      Georges Racinet authored
      This is in particular useful because it makes the return type of
      the `spawn_blocking` call explicit, a hint that the compiler would
      request even for so simple a method as `FindCommit`.
      
      Like `load_repo_and_stream()` it takes care of converting some errors
      into the proper `Status`, still letting the caller define what happens
      with `RepoSpecError`, which may have to differ from one request to the other.
      8b6fdf35
    • Georges Racinet's avatar
      RHGitaly: comment typo · 12caab4c
      Georges Racinet authored
      12caab4c
  20. Jun 16, 2023
    • Georges Racinet's avatar
      RHGitaly: GitLab revision resolution as node. · 734564f0
      Georges Racinet authored
      The `gitlab_revision_node_prefix()` function will be used in all
      gRPC methods that accept arguments that are single GitLab revisions.
      Even those that take ranges would use it, just less directly.
      
      `CommitService.FindCommit` would be the most straightforward case,
      but there are many more.
      
      Closes #126
      734564f0
Loading