- Mar 06, 2025
-
-
Georges Racinet authored
We are basically putting almost everything under the `heptapod` section, because 1. it makes clear to the users that the meaning of the configuration is specific to Heptapod 2. it avoids future collisions 3. it can be readily updated from the Rails app (case of the `heptapod.clone-bundles` item. Caveat: the `disabled` value can be used to prevent all auto-generations, but it will not be possible to disable serving of existing clone bundles at this point (the only way would be currently to disable the `clonebundles` extension, which probably cannot be done from `uipopulate`).
-
Georges Racinet authored
When running under WSGI, if we need to spawn a subprocess, as will be the case with clonebundles integration, we meed to set `HGRCPATH` in the subprocess environment, hence we need to remember the value.
-
- Feb 19, 2025
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Feb 17, 2025
-
-
Georges Racinet authored
Will be useful in HGitaly tests
-
- Feb 19, 2025
-
-
Georges Racinet authored
Its own `test_git` is a good example of how it can be useful.
-
- Feb 11, 2025
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Unfortunately, 5.0.3 was released from the wrong head (forgot to pull). Hence we will have to release a 5.0.4 immediately
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
As heptapod#2021 demonstrate, special refs are a liability (a keep-around in this case). At this point, the command is used for mirroring to external Git services only (no more rollback of the native migration), so we simply stop synchronizing any special ref. Also, we treat the case where some Mercurial changeset is not properly mapped to Git (hard to come by in unit tests). In this case, we do not sync the ref, log a warning, and also avoid to remove the ref from the Git side.
-
- Jan 22, 2025
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jan 21, 2025
-
-
Georges Racinet authored
These were made for Heptapod 17.6.2
-
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
In the default branch, we have already stopped calling by mere instantiation of the handler the "ensure" method and the resync of the Git repo (supporting the mirrors for native projects). It is now done from the commands themselves, hence the tests have to be slightly adapted to call them as well.
-
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 12, 2025
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Two helpers for in-RAM activation on the Mercurial `localrepo` object and in config dicts of our testhelpers for persistence in `.hg/hgrc`. This makes it easier to use in HGitaly test fixtures, reducing hardcoding and duplication.
-
Georges Racinet authored
-
- Jan 06, 2025
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Of course, removing the `no-git` flag for native Projects and behaving as if it were always true is worth a major version bump.
-
- Jan 01, 2025
-
-
Georges Racinet authored
The conversion is now handled by the separate `hpd-export-native-to-git`, to be called ultimately by the Rails app only for Git-push mirroring. The separate command was already existing, as it was supporting the rollback of the native migration, we just gave it a new alias. It takes care of moving the Git repository to its expected location if it turns out that it escaped the migration doing so and is still right beside the Mercurial repository. Releasing this is the first step of heptapod#1963
-
- 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
-
- 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.
-