- 19 Nov, 2020 6 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
Just to avoid any surprises, and besides it's more consistent to have the new versioning scheme for both.
-
Georges Racinet authored
NOT_FOUND is actually used in case the repository is not found only. Most calls will return their default value (0, empty string or `False`) if a lookup fails. Validated by corresponding RSpec tests and/or Golang reference code comparison.
-
Georges Racinet authored
If we have one failed lookup (for instance, ambiguous prefix), we must just ignore the given oid. We keep the simple and fast revset that will take care of the most common case of passed oids being actually prefixes that are long enough. Also behaviour if all lookups fail is to return an empty list, not to return NOT_FOUND error (means repo not found)
-
Georges Racinet authored
This was actually written in a comment right after the change, and validated by RSpec tests.
-
Georges Racinet authored
For instance, the main client (Rails app) remaps it to Gitlab::Git::Repository::NoRepository
-
- 17 Nov, 2020 1 commit
-
-
Georges Racinet authored
Same thing that our current hg-git conversion does, *but* this is known to have performance issues on large repositories. Putting this on a call path that the client has every right to think is cheap is very problematic. I would prefer a simple rule that Heptapod never exposes any obsolete head in its branch queries. The rationale for that would be that by definition Git does not either present any unreachable commit. For the time being (Heptapod 0.17), the projects backed by HGitaly are highly experimental, so we can probably live with it.
-
- 18 Nov, 2020 2 commits
-
-
Georges Racinet authored
As the comment explains, this is for now the only way to let the Rails app actually know that the default branch hasn't been set yet. After a lot of defaultings in the applicative code, this eventually activates the code that's responsible for actually setting it while receiving the first push. We can do something much more robust and maintainable, but that will be after the first push. Meanwhile, we do have functional tests about that to cover our backs.
-
Georges Racinet authored
We introduce a flag in the inner function that sorts out what to do of the branchmap entries, and use it for the default GitLab branch only. As the test demonstrates, the default GitLab branch will still point to the latest bookmarked head, which is consistent with what happens with "wild" multiple heads. This is a minor change of behaviour compared to the Heptapod standard, in which the default GitLab branch would not move in that case. The reason is that we don't have a natural support to store the previous position of the default GitLab branch. Of course hg-git based repositories have/had this extra state, in the form of the actual Git branch. The new behaviour is not worse and as much arbitrary as the previous one, and will of course be matched by py-heptapod's mirrorring to Git.
-
- 17 Nov, 2020 7 commits
-
-
Georges Racinet authored
In many cases, the client will send revision specification also in ref form, e.g, `refs/heads/branch/default`. We were already resolving branch names and tags, now we have to support this, too. We should do something similar about tags
-
Georges Racinet authored
The Rails app will store some changeset IDs and get back to HGitaly for information after a while. For instance, this is what happens with Merge Requests. It's perfectly possible that the changeset has become obsolete in the mean time. Hence the right thing to do is to make these commit methods work on the unfiltered repository. In order to mutualize, we're actually making the `gitlab_revision_changeset` return also obsolete changesets if queried by exact hash. This is consistent with the Git case: a ref should never be obsolete, but an exact lookup can return unreferenced commits. In the tests, it was about time for the `make_empty_repo` helper to activate the evolve extension. Thankfully no other test is affected (without evolve, `amend` would strip the previous changeset)
-
Georges Racinet authored
We will probably have to factorize this for reuse in FindCommits and the like. We'll see.
-
Georges Racinet authored
This one was in the way of the current goal: getting the functional tests to pass.
-
Georges Racinet authored
Again one on the path to get functional tests pass.
-
Georges Racinet authored
This also brings the coverage up to 100% by actually testing the `not_found()` helper.
-
Georges Racinet authored
As said in the docstring, we don't gain that much, especially with the caller probably needing a multi-line statement. Still it's a bit less painful to use, and good for uniformity.
-
- 15 Nov, 2020 1 commit
-
-
Georges Racinet authored
Same as done yesterday with py-heptapod, we can't make it a blocker that the tests pass against the current head of the Mercurial default branch.
-
- 10 Nov, 2020 3 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
We already had good enough error responses for the case when the *storage* is not found, but it was missing for the case when the repository is not found in an existing storage. This is important, because it can actually break the landing page of some users: the Rails application does not seem to expect an unspecified Gitaly error here, but it should recover from NOT_FOUND. I've been impaired by this on dev setup after with some repository removals, but don't have anything of that kind on hand any more, which would be more reassuring. We could have a better separation in concerns, as the subsequent change in `RepositoryExists()` indicates, but that's not a blocker for the imminent release.
-
- 09 Nov, 2020 5 commits
-
-
Georges Racinet authored
It actually fixed the Commit page right away. Direct links in Notes work as well (as expected). Error treatment is coarse: the point is to have a proper NOT_FOUND rather than a crash. Perhaps we will have eventually to ignore problematic oids instead, we'll see that later. Closes #22
-
Georges Racinet authored
As explained in the comment, we must really use `file()` here.
-
Georges Racinet authored
This relies heavily on the previously introduced `not_implemented()` helper method. Many of these look to be short forms of `FindCommits`, probably for bandwidth reduction, and should therefore be easy to implement.
-
Georges Racinet authored
Actually there was but one, in `RefService`
-
Georges Racinet authored
We're providing the `errors.not_implemented()` function with the goal to make it easy to produce proper such errors with links to tracking issues, while needing only one "no cover" pragma comment. For integration testing, we simply selected a RPC method that is unlikely to be implemented ever in HGitaly.
-
- 31 Oct, 2020 1 commit
-
-
Sushil Khanchi authored
For now, this doesn't support all lookups, but we plan to complete it by HGitaly1 milestone.
-
- 01 Nov, 2020 3 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
The new script takes care of switching imports to the relative style that is needed in our context.
-
- 28 Oct, 2020 1 commit
-
-
Sushil Khanchi authored
For now, this doesn't support all lookups, but we plan to complete it by HGitaly1 milestone.
-
- 16 Oct, 2020 1 commit
-
-
Georges Racinet authored
This raises the question of homegeneity of branch naming conventions between py-heptapod and HGitaly (see long comment, with reference to heptapod#352) There was also a glitch while installing py-heptapod. The solution adopted is a path of least resistance.
-
- 15 Oct, 2020 5 commits
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
It is, indeed, read from `setup.py`
-
Georges Racinet authored
The usual mistake that becomes blatant at first actual production of a distribution.
-
Georges Racinet authored
HGitaly now uses some helpers that are not present in the latest released version of py-heptapod (known as `heptapod` as a Python project), hence we have to base our requirement on a pre-release distribution (which was just uploaded).
-
- 13 Oct, 2020 2 commits
-
-
Georges Racinet authored
In the GitLab application, this is used for download links in "subtrees" of the repository. An archival metadata file is not expected (nor is it on the Git side). I've checked that `git archive` behaves similarly, i.e., just an inclusion rule, with no re-anchoring of the files at the top of the archive.
-
Georges Racinet authored
We'll need to perform the same kind of validation on paths that Gitaly does, and Mercurial itself already provides us with utilities to re-expose.
-
- 12 Oct, 2020 1 commit
-
-
Georges Racinet authored
Closes #6 The `path` parameter is not interpreted yet, this will be done in a subsequent changeset.
-
- 13 Oct, 2020 1 commit
-
-
Georges Racinet authored
Gitaly centralizes the sizes of chunks for streaming of binary large objects, with default values and tuning possibilities from environment. We are doing the same here. First use case will be repository archive production.
-