- Oct 10, 2020
-
-
Georges Racinet authored
This provides a more natural and easier to test setting, with the extension being now only a thin wrapper for command-line arguments, configuration and startup exceptions. This also makes inner code more natural by stopping to insist that any string must be bytes: URLs are now str in `hgitaly.server`. On the other hand, storage root paths will keep on being bytes, as is natural for file system paths.
-
Georges Racinet authored
In cases of socket bind failures, grpcio 1.31.0 returns a zero port value, whereas 1.32.0 raises RuntimeError. To avoid making special cases that seem useless, let's just make explicit that we are using at least 1.32.
-
Georges Racinet authored
See heptapod#353 for rationale. Actually, this is more along the lines of not bothering about *potential* Python 2 support, as HGitaly wasn't really working under Python 2 anyway, notably because of type annotations (granted, we could have dropped them, but it doesn't matter any more).
-
- Oct 09, 2020
-
-
Georges Racinet authored
Closes #8
-
Georges Racinet authored
With the accompanying tests, this brings the coverage to 100%
-
Georges Racinet authored
This standard way to return errors to the client is by means of `context.set_code()` and `set_details()`. Some Python exceptions are automatically converted into errors, but with potential loss of information. The new test brings the coverage of repository_service to 100%
-
Georges Racinet authored
Before the issues were created, the coverage could serve as a reminder that they have to be done. This is not useful any more, we'd prefer the coverage to be useful in itself (missing tests, code becoming unexpectedly dead…)
-
- Sep 28, 2020
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
This module will include logic to provide tag messages etc.
-
- Sep 14, 2020
-
-
Georges Racinet authored
Despite its name, the expected return value of `FindAllBranchNames` is actually full Git refs, such as `refs/heads/git_branch_name`.
-
- Jul 30, 2020
-
-
Georges Racinet authored
I can't remember why it's not been done in aaea40d0ae4a, and there's no note about that: it must have been a mistake. We currently have some unrelated failures in the 'stable' build due to Mercurial stable be apparently 5.5 now
-
- Jul 29, 2020
-
-
Georges Racinet authored
Apparently, `None` as default argument for an option is incompatible with it having a value. The only way to detect a missing string argument is to evaluate to bool. In this case, it's not a problem.
-
- Jun 27, 2020
-
-
Georges Racinet authored
These two methods are called early by the Rails application.
-
Georges Racinet authored
The catch is that CommitsBetween is not exactly what one may think: see docstring and comment in tests about checks done for the expected response in a case where `from` is not ancestor of `to`.
-
Georges Racinet authored
We're using it for now from `CommitService` only, but it's prone to be widely reused.
-
Georges Racinet authored
At least for a while, we will address files and directories for Mercurial revisions in a different way.
-
Georges Racinet authored
-
Georges Racinet authored
Because we use generally `make_empty_repo()` with a temporary directory fixture which is scoped at module level, we need repositories to have distinct relative paths in a given test module. Usually, choosing such unique paths is a useless distraction, it's better to simply generate them. In turn, that means it's better if the repo path can be retrieved from the wrapper. It was already available as `wrapper.repo.root`, which is less convenient, being a `bytes`.
-
Georges Racinet authored
This is consistent with the earlier creation of the `hgitaly.service` package, but it means that some relative imports become less practical. We'll probably end up making a few proper fixtures, but it's better to do that once we know exactly what we need.
-
Georges Racinet authored
as usual, we're postponing various error treatment. In this case, checks for missing inputs (with messages cited from Gitaly reference Golang impl), and for not found changesets.
-
Georges Racinet authored
It will be useful for various other tests than for `ListBranchNamesContainingCommit`
-
- Jun 28, 2020
-
-
Georges Racinet authored
With the updating logic in `py-heptapod` and in the Rails app, we should never have to fallback to the hardcoded `branch/default`, except maybe on empty repos. Of course future migration of `hg_git` projects to `hgitaly` project will copy over the default branch information from the auxiliary Git repo to the Mercurial repo.
-
Georges Racinet authored
Despite its name, `FindDefaultBranchName` is actually expected to return a branch ref instead of a branch name. Given something else than a branch ref, the Rails app `Gitlab::Git.branch_name` returns `nil` (as of GitLab 12.10)
-
- Jun 23, 2020
-
-
Georges Racinet authored
This assumes that a tag id is the id of the changeset that's responsible for it, i.e that the hard part is done.
-
- Jun 20, 2020
-
-
Georges Racinet authored
This is partial because we don't have at the moment a clear way to get the commit responsible for the tag value, which would be needed to provide authorship and tag contents. In `mercurial.tags`, what is called `hist` is a list of previous tag *values*, hence is not what we need. Trying to reproduce the tag resolution logic, even with knowledge of the target changeset looks to be at best risky. Efficient extraction of that information would probably entail doing it along the target node information, and probably more caching.
-
Georges Racinet authored
- decided to use the 'SPEC' marker wherever what's expected is not clear. Does not imply a formal specification can really be found. - tagtype() uses caches, so the comment was either obsolete or overblown.
-
- Jun 23, 2020
-
-
Georges Racinet authored
of course it does nothing. Contrary to `ListNewCommits`, calling it is not a hard error, as calling it by mistake is somewhat harmless (less critical than pre-receive checks).
-
Georges Racinet authored
All explained in the docstrings, we probably never will implement them for Mercurial. On the client side, all currently existing callers must be rewritten anyway.
-
Georges Racinet authored
Same as sibling method for branches, we'll have to cope with ordering, but that can probably wait.
-
Georges Racinet authored
At this point, the ordering of results is arbitrary. We don't expect that to be a problem until after the first end-to-end experiments. Implicitely expected ordering is specified in comment. Implementation is probably somewhat inefficient. It's a bit frustrating that in Mercurial we know right away to which branch a commit relates (contrary to Git) but still have to do all these ancestry computations. But it would be easy to be wrong if trying to be smarter.
-
Georges Racinet authored
This is a simple way to limit the number of items in responses, although we expect many cases to actually be better implemented by passing the limit down to the thing that produces the iterable being chunked
-
- Jun 20, 2020
-
-
Georges Racinet authored
We could want a different behaviour later on: - silently ignoring the request (for now we're happy to have errors as a bug catcher) - close branches if that is relevant (but perhaps we'll want a new rpc call for that).
-
Georges Racinet authored
Obviously, it's fast to simply get the changeset for any `wild/hexnode` GitLab branch, but it's incorrect if that changeset does not really qualify as a wild head.
-
Georges Racinet authored
we still have ambiguities to lift with wild heads, and must take care of special refs, such as keeparound etc.
-
Georges Racinet authored
-
Georges Racinet authored
It will host factory functions which are useful for several services, so typically for messages defined in `shared.proto`.
-
Georges Racinet authored
actually should have been committed with 5cca85c5e7f5
-
- Jun 19, 2020
-
-
Georges Racinet authored
It's always been the intent, but some drift occurred due to `FindBranch` being way after `FindAllBranches`.
-
Georges Racinet authored
In this first implementation, that's easy: there is no concept of remote branches in Mercurial. Although, on second thought, in GitLab they could be related to mirroring features, and we may need to have something similar for Mercurial at some point which would be provided by an extension, that we'd write ourselves if it doesn't exist already.
-
Georges Racinet authored
It looks as if the `commit` field was added last, and that would explain why the redundancy.
-