- 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.
-
- Nov 18, 2020
-
-
Georges Racinet authored
Instead of ignoring the prune (and hence making a slight discrepancy between Git and Mercurial content), we will refuse the transaction. Someone with enough commit rights to close the default branch can surely change it in the Heptapod project settings. This is ultimately because the native mode reads Mercurial content only. Of course, when it doesn't perform Git conversion, we'll still have to port that check, but the functional tests are also covering this, so we'll know.
-
Georges Racinet authored
As explained in the doctest, this is very unwanted. Up to now we were just removing that prune at the end of the process. With the native mode (currently still using hg-git) we can't do that any more: we will need instead to abort the transaction if there is such a scheduled prune (mostly for other reasons, such as closed heads). Therefore the simplest here is to not schedule the prune.
-
Georges Racinet authored
We split out the filtering logic and (GitLab) branch prune scheduling related to masking by bookmaks, before we add more rules to it, without changing any outcome for now. This is also an opportunity to clarify the comments and move them up the ladder: it's always nicer as a docstring.
-
Georges Racinet authored
This is a simple refactor, but we take the opportunity to explain the difference with the "default GitLab branch" of native repositories: they're stored differently, should be equal wherever it makes sense (it won't when native repositories won't use hg-git except for mirroring).
-
Georges Racinet authored
This puts it in conformity with its docstring. Actually the Rails app doesn't make anything of it at this point, but this was done along the way.
-
- Nov 17, 2020
-
-
Georges Racinet authored
-