- 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.
-
Georges Racinet authored
For instance, the missing dependency on `attrs` in 1.1.2 would have been detected with this.
-
Raphaël Gomès authored
-
Raphaël Gomès authored
-
- Dec 01, 2020
-
-
Georges Racinet authored
Part of heptapod#351 Suprisingly, reading HEAD with dulwich takes 25ms, and we were doing that for all branch/topic combination. The penalty is harsh when running for repositories with hundreds of branch/topic combinations. Caching this gets the time to perform a push on PyPy in my dev setup from 45s to about 4s. We could have avoided the caching, but there are some other callers, why spending occasional 25ms when we can avoid it? This is the occasion to move the setting logic in a separate method, awaiting the later refactorings for separation of "native" case from hg_git case.
-
- Nov 30, 2020
-
-
Georges Racinet authored
-
- 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...
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
- no more side effects on the `hg_shas` set, actually can be any iterable now - explicit namings for better maintainability: result_sha, wild_sha instead of over-using hg_sha
-
Georges Racinet authored
There was previously still room as to how the choosing would happen, but we've since then settled to what Mercurial does by default, even if this is unsatisfactory, it has the less chances to create blocking situations in practice. That means that only lookup failures and the empty set corner case remain in `multiple_heads_choose`. We're making it resist the failures and have its caller loudly complain in the logs.
-
Georges Racinet authored
The case where the push is inspected to upgrade the default gitlab branch from a topic to a named branch but does still not provide any visible named branch head was previously only covered by `test_multiple_heads_cannot_choose`, that we will push down to the inner tests soon.
-
Georges Racinet authored
-
Georges Racinet authored
In the just extracted `branchmap_entry_process_finalize`, these more self-defining parameter names will avoid ambiguity.
-
Georges Racinet authored
The new method responsibikity is actually to assess multiple heads and take care of storing the results in the exportable dict, because it may need to create new entries (in the `wild` namespace)
-
- Nov 28, 2020
-
-
Georges Racinet authored
See heptapod#351 This prevents the expensive `_filter_obsolete_heads` to be called twice on each transaction: the first in evolve's `enforcesinglehead`, the second in our analysis code for GitLab branches. In 1.1 versions, we don't want to change the meaning of configuration flags, hence we still react to `experimental.single-head-per-branch`. In the future 1.2 versions, however, we will ignore that flag and base everything on `heptapod.allow-multiple-heads`, hence sparing us the monkey patching.
-
- Nov 27, 2020
-
-
Georges Racinet authored
This almost data class is a typical use-case for `attr.s` (just had a debugging session where a `repr()` implementation would have been handy). I would never be confident about positional args in constructor with that declarative style, so changed the constructor arguments usage in main code, even if more verbose.
-
Georges Racinet authored
This was detected by the `test_push_corrupted` functional test. It is a bit irritating to still have to take care of that with native projects, but the truth is that all the analysis logic really needs to be based on Git SHAs because Git actually plays the role of the GitLab branch map that we don't have.
-
Georges Racinet authored
the backport is released in dulwich 0.20.14 and our unit test proves that it has indeed been included, as expected. Not removing the backport yet because py-heptapod is still pinned to an older dulwich, but will do as soon as I have time to check the changes that bumping to the new release will also bring (expecting bugfixes only).
-
Georges Racinet authored
-
Georges Racinet authored
Forgot to commit/tag yesterday
-
- Nov 24, 2020
-
-
Georges Racinet authored
Sub-classing Dulwich whole testcase brings in all the tests from that class, but we don't care: they pass in less than a second. Given the release rate of dulwich, a new version should be available soon, but we haven't tested anything from 0.20.5. It doesn't look like the best time to update. In any case the backport gives us more options. Closes heptapod#370
-
- Nov 23, 2020
-
-
Georges Racinet authored
-
- Nov 22, 2020
-
-
Georges Racinet authored
This is of the same spirit as in mercurial-testhelpers. We keep a compatibility alias for downstream projects, such as HGitaly and hg-loggingmod, but we should be able to get rid of it soon.
-
Georges Racinet authored
These testhelpers have been externalized as the `mercurial_testhelpers` package. The latter being meant to be identical to a future `mercurial.testhelpers` in Mercurial core, they don't have facilities for topics nor evolve specific commands. But the commit options extensibility can be used to specify topics in `commit_file`. As for the `prune` helper method, it can be implemented by direct subclassing. This is what `hg-evolve` could later do, if that project were to adopt those test helpers. Downstream extensions of evolve and topic could then just use a base class provided by evolve. Also, the `RepoWrapper` from `mercurial_testhelpers` has two different method names, that we remap directly to make the whole test suite pass.
-
- 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
-
- Nov 11, 2020
-
-
Georges Racinet authored
This is typically used with an explicit `branch` keyword argument.
-
Georges Racinet authored
This is the equivalent to `hg rm` for a single file.
-
Georges Racinet authored
it will both be the base for new helpers, and directly usable as demonstrated by the new test case.
-
Georges Racinet authored
it will be used in forthcoming new helpers
-
Georges Racinet authored
it will be useful in forthcoming new helper methods
-
- Nov 21, 2020
-
-
Georges Racinet authored
The point is to get warned, not to block unrelated development of py-heptapod.
-
Georges Racinet authored
Even though it's fast, it's just not needed to run the same thing many times. Of course it's in the first stage.
-
Georges Racinet authored
I often run it manually anyway and if I forget to do it, it happens frequently that I get a CI failure. The `HEPTAPOD_CI_SKIP_LINT` will be useful to avoid running it more than once.
-
Georges Racinet authored
With more development happening in hg-git right now, it makes sense to check compatibility. This is done by moving the installation of dependencies aside in its own script and make it react to a dedicated environment variable.
-
Georges Racinet authored
Notably in CI, we'll use it to keep checkouts of some live dependencies, such as hg-git.
-
- Nov 19, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
(this is used to test the presence of environment variables, notably for user hooks). The result would be inconsistent between SSH and HTTP access. Another solution would be to add the variable to the HTTP case (forwarding in WSGI wrapper), but that's an implementation detail for real consumers, so we did not.
-
Georges Racinet authored
All operations performed on the Rails app work within a temporary share. Therefore, if users create their first changeset from the web app, we have to set the default GitLab branch in the actual repository.
-