- Feb 23, 2021
-
-
Georges Racinet authored
With the given defaults settings, clients won't see any difference. hg-configexpress 0.4.0 passes all tests with Mercurial 5.6, the series we're using in current Heptapod. The question of how to configure selected projects is entirely open. For now, users have to modify the repo (or group) HGRCs on the server file system. Since there are auxiliary files, the question of backuping them is also open. Closes heptapod#190
-
- Jan 28, 2021
-
-
Raphaël Gomès authored
We will be using new config options only available from this version up.
-
- Dec 02, 2020
-
-
Georges Racinet authored
The default configuration has been using it for a while. Of course in production Heptapod context, that's always provided (by the requirements shipping with the Rails app), but it can be missing in some development contexts - that is a pain, and potentially a waste of time because anything output on stderr is considered an error if spawned from Rails.
-
- Nov 29, 2020
-
-
Georges Racinet authored
This made 1.1.2 unusable outside of dev environments. Thought it was automatically provided because Mercurial uses it. Big mistake, Mercurial vendors it. Of course can't be detected by a pytest session...
-
- Nov 21, 2020
-
-
Georges Racinet authored
Notably, we don't need the python2/python3 markers, because we don't support Python 2.7 any more
-
- Aug 25, 2020
-
-
Georges Racinet authored
For the record, dulwich 0.20 dropped Python 2 support.
-
- Jun 08, 2020
-
-
Georges Racinet authored
Apparently, the recently released dulwich 0.20 requires Python 3
-
- May 13, 2020
-
-
Georges Racinet authored
hg-evolve 10.0.0 supports Mercurial 5.4
-
Georges Racinet authored
On Mercurial 5.2, there was no official compatible version yet. We were using tags put in the legacy Heptapod fork of hg-git. The freshly released hg-git 0.9.0a1 is compatible all the way up to Mercurial 5.4
-
- May 09, 2020
-
-
Georges Racinet authored
-
- May 06, 2020
-
-
Georges Racinet authored
As of hg-evolve 9.3.1, some obsolete heads are ignored in the protection agains multiple heads. These happen typically in stacked topic scenarios, after amendment of the anterior topic. These should not count as multiple heads in our exposition to GitLab either, we're applying the same function to filter them out. This has us convert systematically to changeset contexts (standard abbrev being `ctx`) whereas we were doing so before only in the loop to ignore closed branches.
-
- Apr 30, 2020
-
-
Georges Racinet authored
-
- Mar 10, 2020
-
-
Georges Racinet authored
This implements the `post-receive` hook by a direct HTTP call to the internal API endpoint. For this, two new config parameters in the `heptapod` section are introduced: - gitlab-internal-api-secret-file - gitlab-internal-api-url We're keeping the previous structure, with a `name` that's now almost useless and leads us to the complication of the `_hook_methods` dict. This keeps compatibility for the caller (also part of this package since Heptapod 0.12), allowing us to refactor in a separate step.
-
- Apr 23, 2020
-
-
Georges Racinet authored
In this branch, we won't care about Mercurial 5.4, for which our tests are broken. The tests broken on the hg stable and default branches have already been fixed in the default branch of this project.
-
- Mar 09, 2020
-
-
Georges Racinet authored
This is done by subclassing `GitHandler`, for now adding `update_exportable_for_named_branches`, almost identically. The only functional difference is that named branches and topics are always exported, i.e., not depending on the value of `hg-git.export-named-branches`
-
- Dec 15, 2019
-
-
Georges Racinet authored
-