- Jun 27, 2020
-
-
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.
-
Georges Racinet authored
This was left aside in the project bootstrap. We won't actually need multiple storages for a while, hence the server command still uses a single `repositories-root`. But we better have the internals support multiple storages right away: its easier to do right now than to add it afterwards.
-
- Jun 18, 2020
-
-
Georges Racinet authored
As the comment in test says, using `branch=None` translates in an actual `Branch` message with empty `name`, and this has been checked to be the proper representation for "lack of branch": gRPC doesn't have null/nil/None, using default values instead (reminescent of String rules in Golang).
-
- Jun 17, 2020
-
-
Georges Racinet authored
Not having an actual caller in the Rails app besides exposition through Repository (which doesn't have callers) doesn't make it a priority target.
-
Georges Racinet authored
We're excluding local tags, and more importantly, `tip`, whose type is `None`
-
- Jun 18, 2020
-
-
Georges Racinet authored
All the work is done by `iter_gitlab_branches()`.
-
Georges Racinet authored
This is not tested at this point, but also brings bookmarks support.
-
Georges Racinet authored
The functions in this module enforce the Heptapod rules to map addressable Mercurial content to GitLab branch, in particular: - named branches and topics to GitLab branches - multiple heads conventions - bookmarks
-
- Jun 17, 2020
-
-
Georges Racinet authored
One has found its final place, the other one has moved from HGitaly's commit service to heptapod.gitlab
-
Georges Racinet authored
A side benefit of `--doctest-modules` is that it will import all Python modules (looking for doctests in them), and by doing so, it will find missing `__init__.py` files and other inconsistent imports.
-
Georges Racinet authored
It seems that many streaming Gitaly responses are actually streaming responses which themselves contains chunks of content. An example would be `RefService.FindAllBranchNames`. Couldn't find anything really convincing in `itertools` for that.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
and as always, if it ain't tested, it ain't working.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
The previous way to create a topic changeset simply did not work, revealed by switch to testhelpers topics facilities from py-heptapod: the call to `FindCommit` was also done for the wrong GitLab branch! Taking into account a small trap: the config set on the wrapper is transient (akin to command line arguments), therefore it doesn't apply on the HGitaly server side.
-