- Jan 22, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
The only change is `git_branch_ref` that is simply `gitlab_branch_ref` (it was already imported `as`)
-
Georges Racinet authored
The only changes are to the uniform "GitLab" terminology (from "Git").
-
Georges Racinet authored
For native Mercurial projects, these methods will be implemented as the identity. But for hg-git based projects, these express conversion from and to Git.
-
Georges Racinet authored
We start with the default branch management primitives. Also illustrates how this will be an opportunity to switch to a more neutral 'GitLab' terminology instead of 'Git'. Indeed the former will be considered appropriate, even when Git is not involved, i.e., with native Mercurial projects and this is in line with previously already used `gitlab_branches` etc.
-
- Jan 23, 2021
-
-
Georges Racinet authored
First step in extraction effort of common components between hg-git based and fully native repos. Still not fully decided about shortening it to `RefChange`.
-
- Jan 21, 2021
-
-
Georges Racinet authored
This command will be useful for direct calls from the Rails application (backups code is the first use case). Closes #8
-
Georges Racinet authored
This will make HGitaly able to rely on the file presence.
-
- Jan 22, 2021
-
-
Georges Racinet authored
This is more convenient in some integration tests scenarios
-
- Jan 21, 2021
-
-
Georges Racinet authored
-
- Jan 05, 2021
-
-
Georges Racinet authored
The `BASE_IMAGE_COLLECTION` variable for the pipeling of py-heptapod masks the one defined in the pipeline of HGitaly, which changed with the introduction of the comparison tests with Gitaly. Decided arbitrarily to have the variables in the py-heptapod pipeline as in the HGitaly pipeline. Could have gone the other way.
-
- Dec 20, 2020
-
-
Georges Racinet authored
While the integration tests of py-heptapod have been happy with the `repo.hg`/`repo.git` combination up to now, this is largely due to their fixtures having the `function` scope: each test function runs with its own temporary directory. But this fixture support class will also be used in the Gitaly comparison tests of HGitaly, where the storage repositories have the `module` scope. These want to supply randomized names for the repos to provide the necessary test insulation.
-
- Dec 19, 2020
-
-
Georges Racinet authored
In some cases, the variables shortcut are almost as long as the previously partly factorized setup, but this is clearer in many ways. An important feature is that we should be able to reuse many of these tests in the forthcoming changes for Mercurial-native Heptapod projects, for which hg-git won't be used any more, but we'll still have GitLab notifications etc. We don't need `make_main_repo()` any more, since `main_fixture` was created by duplicating its committing.
-
Georges Racinet authored
It is fairly basic for now, yet already useful in this form.
-
Georges Racinet authored
The new `GitLabMirrorFixture` will hold the two repositories and the notification interception mechanism. We demonstrate by rewriting only two tests, but the goal is to make all of them just use the new fixtures for better clarity and maintanibility. Another goal is to use this class directly in HGitaly comparison tests with Gitaly (hgitaly#35). The new class is mostly tested indirectly. A minor difference with the previous test is that it actually creates the Git repo (which hg-git would otherwise do anyway). This was felt to be clearer, and tests depending on this won't have to make special cases for when no mirroring actually occurred (can imagine that to happen with tests for error paths).
-
Georges Racinet authored
Even tests that do not care about assertions about notifications sent to GitLab need this, because there is typically not a GitLab Rails application to send requests to. This is a base building block that will be useful in other contexts, such as HGitaly comparison tests with Gitaly.
-
Georges Racinet authored
-
Georges Racinet authored
For better symmetry with upcoming Git helpers. We're maintaining compatibility by re-exposing at the package level.
-
Georges Racinet authored
We're about to have it adopt some more utilities.
-
- Dec 18, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
Fixing problems with obsolescence validation See merge request !47
-
Georges Racinet authored
-
Georges Racinet authored
The transaction on the receiving side will have obsolescence markers about changesets that were obsoleted before any exchange. Of course these are to be ignored.
-
Georges Racinet authored
We didn't test until now the case where the tag is 'tip' and it turns out that the tip of the obsolete repo is the obsoleted changeset in that case.
-
Georges Racinet authored
-
- Dec 16, 2020
-
-
Raphaël Gomès authored
Some repositories (particularly Octobus's `mercurial-devel` instance) do not want to exchange bookmarks, ever. This change applies to all exchange mechanisms relevant to Heptapod but was initially motivated by the new hg pull mirrors.
-
- Dec 17, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
This is a more common trap than with bookmarks, due to the separate changeset introducing the tag. Closes heptapod#393 Like the whole refs update analysis, will have to be kept when we don't mirror to Git.
-
Georges Racinet authored
Sometimes, the changesets created by `make_main_repo()` are just pollution.
-
Georges Racinet authored
In general, making a bookmark obsolete will resolve it: `hg amend` will move it to the successor, `hg prune` will move it to the parent. We found one corner case to make the target of a bookmark obsolete (`hg prune` when there is no parent). But there may be other ones (`hg split` maybe?)
-
- Dec 15, 2020
-
-
Georges Racinet authored
This is the bare minimum needed so that downstream users such as HGitaly can leverage it. The final version should probably become a property on the repo instance, but that will require actually more work, because it's not immediately clear if the standard Mercurial tooling applies well in this quite special case, namely: - we don't want any invalidation to occur before the explicit write at the end of transaction, for consistency reasons: the very mission of the state file is to represent the state at the beginning of transaction. - we're working under the assumption that all writes to the repository will update the state file. This is true, yet very specific to the Heptapod server environment. It's fine for `read_gitlab_branches` to raise `FileNotFoundException`. Will have to see for other exceptions though.
-
- Dec 14, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
It's not needed, but it's even better if we don't activate it nevertherless.
-
Georges Racinet authored
In other words, adapt to our own config option removal!
-
- Dec 12, 2020
-
-
Georges Racinet authored
Of course, all this back-and-forth conversion from Git SHAs to Hg SHAs is getting long. The goal at this point is merely to make it available right away to HGitaly. Later on we'll have to split the branch analysis logic, and we'll start having a handler for Mercurial native projects, that will eventually not convert to Git at all.
-
Georges Racinet authored
As explained in the long docstring, this represents the latest state of branches *transmitted* to GitLab, i.e. has to be considered the state at beginning of transaction if there is an ongoing one (used precisely to deduce changes to notify GitLab about) or the current state if there is no ongoing transaction (read-only case). The read-only case will be useful for HGitaly right away: instead of doing expensive computations for each branch read, it will leverage this file if available.
-
Georges Racinet authored
These were long-standing TODOs.
-
Georges Racinet authored
The change in configuration flags for multiple heads is a non backwards compatible change.
-