- Nov 20, 2023
-
-
Georges Racinet authored
It was a mistake to depend on `load_repo`, as it will fail if, e.g., the `.hg` sub directory does not exist (seen in Rails RSpec tests) and various corrupted cases that a *removal* should clean up. The price to pay is the transactionality of the roster, but we cannot lock it properly without a repo. In theory in should be possible to instantiate the `Vfs` separately, but it does not seem to matter so much. With this change, if removing the working directories fails, it will not prevent removing the trashed repository (but of course we risk a later collision in workdirs). Backs out in particular changeset 1c735d40cfe7
-
- Nov 18, 2023
-
-
Georges Racinet authored
-
- Nov 15, 2023
-
-
Georges Racinet authored
The error message is ``` *** failed to import extension "hgitaly": unicode '[OPTIONS]...' found in cmdtable.hgitaly-serve ``` It is completely obscure why this has not been a problem before. Got this with Mercurial 6.4.5, then 6.4 on Python 3.9 (usually running with Python 3.10 if that makes any difference).
-
- Nov 13, 2023
-
-
Georges Racinet authored
-
- Nov 18, 2023
-
-
Georges Racinet authored
Now that we need to load the repo for the working directories machinery, no need to repeat the exceptions that can be raised by the loading. The only difference lies in the error message on missing repository, which we are confortable ignoring.
-
Georges Racinet authored
This is obviously useful to avoid wasting disk space, but also prevents vicious errors when repository paths are reused, which happens mostly in RSpec tests such as `spec/lib/gitlab/mercurial/hgitaly_*_spec.rb`
-
- Nov 12, 2023
-
-
Georges Racinet authored
We chose to use the same detector as Gitaly's: go-enry/go-license-detector, so that we get the same results. Of course this means we have to provide it in CI and Omnibus builds. Closes #161
-
- Nov 16, 2023
-
-
Georges Racinet authored
It was already duplicated between `test_errors` and `test_linguist` and will be useful in other cases. We had to rename it a bit to make it more explicit out of the context of a given test module.
-
- Nov 14, 2023
-
-
Georges Racinet authored
-
- Nov 10, 2023
-
-
Georges Racinet authored
In the case of unknown storage, we find it useful to repeat the requested name, hence we simply stop comparing exactly the details. In the case of the missing repository field, the new upstream message is clearly better, so we adopt it.
-
Georges Racinet authored
The change appeared between Gitaly 16.0 and 16.2.
-
- Oct 14, 2023
-
-
Georges Racinet authored
See comment of parent changeset (merge stable)
-
Georges Racinet authored
This brings in the new `MercurialOperationsService`, together with its `hgitaly` ruby gem bump. Since we've already tagged 0.41.0, this means the next version should be 0.42.0, most probably with the jump to Gitaly protocol v16.1
-
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 24, 2023
-
-
Georges Racinet authored
-
Georges Racinet authored
It turns out that Gitaly returns an empty response on an empty repository, whatever the value stored as default branch might be. In case the default branch points to a branch that does not exist, it returns the first branch it can find. This latter case cannot happen with the state maintainer provided by py-heptapod. This can be important for various mechanisms to actually set the default branch. We're simply returning an empty response if the default branch is set but its target does not exist. This amounts to the same in all current scenarios. Later on we could return the first GitLab branch if that becomes useful.
-
Georges Racinet authored
This removes another todo comment, providing possible clean reuse, at the price of needing to duplicate some error cases tests.
-
Georges Racinet authored
Closes #153
-
Georges Racinet authored
This is not exactly what was suggested in the removed todo comment, because it contains context-based error treatment and uses repository loading methods, but still provides clean mutualization, that could for instance also been used in `MercurialRepositoryService`.
-
- Sep 21, 2023
-
-
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.
-
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.
-
- Sep 20, 2023
-
-
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
-
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.
-
Georges Racinet authored
-