- Sep 19, 2023
-
-
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.
-
- Sep 17, 2023
-
-
Georges Racinet authored
First working version that should make CI happy, can be improved (CPU and RAM efficiency).
-
- Sep 04, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
With the `CommitService.GetTreeEntries` implementation and the related helpers (chunked streams, pagination protocol), this is worth a minor version bump
-
- Aug 31, 2023
-
-
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.
-
- Aug 30, 2023
-
-
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`.
-
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)
-
- Sep 01, 2023
-
-
Georges Racinet authored
-
- Aug 30, 2023
-
-
Georges Racinet authored
This is the core engine for one of the three modes of `CommitService.GetTreeEntries`.
-
- Aug 31, 2023
-
-
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.
-
- Aug 30, 2023
-
-
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.
-
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.
-
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.
-
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.
-
- Aug 18, 2023
-
-
Georges Racinet authored
Probably more complicated than it should, but it works and can be swapped later to something more straightforward.
-
- Aug 12, 2023
-
-
Georges Racinet authored
Closes #135
-
Georges Racinet authored
This parallels Python's `heptapod.branch.gitlab_branch_ref`.
-
Georges Racinet authored
There were no Gitaly Comparison tests for this very old implementation, and HGitaly response did differ. The comment in the service implementation suggests that the Rails app is actually depending on the previous returned value, so this might break it. Nevertheless, it is so much clearer to enforce the policy that HGitaly responses should be the same as Gitaly's where applicable that the Rails app should be fixed instead.
-
- Aug 09, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
This includes version parsing logic. If the path to tokei changes, its version will be queried again. Otherwise, a service restart would be necessary to adapt to a version change. Closes #149
-
- Aug 07, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Adaptation to match changes of Gitaly error details in `CommitService.TreeEntry`
-
- Jul 31, 2023
-
-
Georges Racinet authored
We put the previously introduced building blocks together and validate with the Gitaly Comparison test, with some improvement needed in its expensive fixture left for follow-ups.
-
- Aug 07, 2023
-
-
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).
-
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.
-
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.
-
- Jul 31, 2023
-
-
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.
-
- May 03, 2023
-
-
Georges Racinet authored
This introduces a new binary dependency on the [Tokei](https://crates.io/crates/tokei) code statistics tool. The path to the Tokei executable is configurable as `hgitaly.tokei-executable`, defaulting to `tokei`. Strict comparison with Gitaly is not fully possible, as Tokei does not produce the very same results as GitHub Linguist (or `go-enry` which is the library Gitaly is currently moving to). For instance `robots.txt` is detected as the `robots.txt` language by Linguist and as `Plain Text` by tokei. That being said, we can compare more frequent results, namely Python and Ruby. We vendor the `languages.json` file from GitHub Linguist to add the color information (not part of Tokei results), with the same defaulting logic as Gitaly (see the detailed docstrings), based on a hash of the language name. We were lucky to find a programming language (COBOL) to base our tests on. It is important to sort the results in decreasing order, because the Rails app considers only the 5 most frequent languages in the repository, and does so by truncating at the 5 first elements.
-
- Aug 06, 2023
-
-
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`".
-
- Aug 05, 2023
-
-
Georges Racinet authored
This job is way longer than the Python tests in the same stage and is needed for Comparison Tests. Most of the time being spent in Rust compilation, it should be worthwile to launch a worker with more CPUs.
-
Georges Racinet authored
In CI, the artifact size is becoming huge (~1.6G), and it's not so useful to rebuild in the `comparison` job, as this is not caching. We introduce the option to take a path to a prebuilt RHGitaly from environment variables, and use it in CI, which allows us to restrict the artifact to the (much smaller) final executable, provided we actually run `cargo build`.
-
- Aug 01, 2023
-
-
Georges Racinet authored
In HDK initialisation, this will be more suitable than sharing from an existing repository (self-contained, would not be forgotten)
-
- Jul 31, 2023
-
-
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.
-
- Jul 30, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
-