- Nov 13, 2023
-
-
Georges Racinet authored
-
- Oct 14, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
hence we publish a Python package and a Ruby gem
-
- Oct 11, 2023
-
-
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.
-
- Oct 13, 2023
-
-
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
-
- Oct 09, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Previous change, climbing the changelog only once, was an improvement but we were still finding out last commit for all the entries of the given subdirectory (aka tree), instead of those inside the offset/limit window.
-
- Oct 08, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
LastCommitForTree... performance improvements See merge request !195
-
- Oct 02, 2023
-
-
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.
-
- Sep 22, 2023
-
-
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.
-
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
-
- 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
-