- Jan 21, 2025
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
and also stop setting it to `master`. This is the root resolution for heptapod#1987
-
Georges Racinet authored
This is obviously to reduce duplication. It is worthwile to note that in Heptapod 17.7, it will be equivalent to which subclass is in use (we still use `HeptapodGitHandler` for native projects with mirrors to Git in Heptapod 17.6). That is why we preferred using a property, as it can simply be replaced by a class attribute later on.
-
- Jan 20, 2025
-
-
Georges Racinet authored
Should solve heptapod#1984, especially given that the migration to native Projects calls `hg move-hg-git-repo-out-of-gitaly-reach`. Given that this is a one shot and we happen to have the same Python dependencies in the default and stable series of Heptapod, we're hardcoding the series in the CI configuration. Obviously to be reverted upon merge in the default branch.
-
- Jan 06, 2025
-
-
Georges Racinet authored
We will soon make it called only when needed (not as part of the regular `gitlab-mirror` command).
-
- Dec 02, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Nov 25, 2024
-
-
Georges Racinet authored
The move command did not create all intermediate directories, hence was failing on the typical GitLab hashed storage structure. In the unit tests, the repositories are at the root of the storage, missing this. Also fixing a minor typo in the sanity check error raising, that would not lead to breakage but was not the intent.
-
- Nov 21, 2024
-
-
Georges Racinet authored
Using `gitlab-mirror` would work, but this one has the advantage of doing nothing else, hence not risking unrelated errors. It also adds some sanity checks.
-
- Nov 10, 2024
-
-
Georges Racinet authored
Part of heptapod#1848. Any invocation of `gitlab-mirror` will move the repo to `+hgitaly/hg-git`. We will introduce a Rails batched migration that calls it, but the point is that there will be no race between the migration and incoming pushes. As for testing, we had to introduce the `GitLabMirrorFixture.reload_git_repo()` method. On the fixture, it is possible to go back-and-forth, but in practice, there is no rollback migration out of native in Rails, and `git.py` does not support moving back either.
-
- Nov 21, 2024
-
-
Georges Racinet authored
This is in prevision of the changes needed to move the Git repos out of reach of Gitaly (see heptapod#1848).
-
- Nov 19, 2024
-
-
Georges Racinet authored
The tests do not work with Dulwich 0.22, see #44. Unfortunately, the tests for Mercurial stable branch (currently shortly before 6.9) do not pass either, and given the install issues detailed in heptapod#1898, together with the fact that I did not reproduce locally, it is not worth specifically fixing.
-
- Sep 04, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
As explained in the commment we cannot prune yet directly, the user feedback should help users check that it disappears later on.
-
Georges Racinet authored
-
Georges Racinet authored
This fixes the scenario of heptapod#1716 in two different ways: - we do not change the default Heptapod branch from one topic to another if not needed. - we check if the topic of the existing default branch has become obsolete and force switching in that case. Then we add some protections against the case where the changes prune the default branch and provide no suitable replacement (such as in pruning the whole topic), so that momentary persistence of the GitLab branch does not shadow the fact that an obselete changeset is being references (this the end cause of the HTTP error 500 anyway).
-
Georges Racinet authored
It would be a bit overwhelming to warn users before hand about starting up with a topic (100% draft repo), especially since that idea does not cross the mind of people not used to topics. However this explicit message as push feedback should help. Same with the one for the more normal case of a public named branch from the onset.
-
Georges Racinet authored
Part of heptapod#1674
-
Georges Racinet authored
Part of heptapod#1674
-
Georges Racinet authored
Part of heptapod#1674
-
- Aug 24, 2024
-
-
Georges Racinet authored
-
- Aug 23, 2024
-
-
Georges Racinet authored
-
- Aug 22, 2024
-
-
Georges Racinet authored
Part of heptapod#1672. Actually the stable and oldstable branches were only differing by a comment (and `.hgtags`).
-
- Aug 19, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Contains the fix to heptapod#714
-
Georges Racinet authored
Obviously, setting the cache attribute had been missing for all this time.
-
Georges Racinet authored
This was the root cause of heptapod#714: reading the value of the GitLab default branch from Mercurial shares was not switching over to the share source where the file is actually stored. On the server side, Mercurial shares are used for all server-originating operations (web edits notably) and they are not used for receiving pushes, explaning why reproduction was only possible with web edits. Also this happens only for native projects (nowadays always without the Git repo to support the default branch information as `HEAD`) hence was amplified when the mode without Git became default. As a result, the default branch machinery was defaulting to the topic.
-
- Aug 08, 2024
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
It turns out that the 4.7.4 tag points to a changeset in which `VERSION` is 4.7.4dev0
-
Georges Racinet authored
-
- Jul 22, 2024
-
-
Georges Racinet authored
Should fix test_package, which is not so much about Python 3.11 but rather the version of `pkg_resources`
-