- May 19, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
(were actually uncommitted local mods)
-
Georges Racinet authored
The source of truth for the default GitLab branch is the HEAD of the Git repository. If we don't set it, then GitLab will, using a random branch of first push (unless maybe 'master' is among them). Further, it's much simpler and clearer to change from here than from the Rails application, because the latter is mostly meant to perform things like protecting the branch, and isn't really meant to set it to anything other that it's already seeing. For the Rails app, it'll just boil down to clear some caches if the situation looks like HEAD is prone to change (e.g the default branch maps to a topic).
-
- May 18, 2020
-
-
Georges Racinet authored
Before this, neither pre-receive nor post-receive notifications were sent. The former would be a major security concern for upstream GitLab, much less for us, since most of the permission checking is actually done by Mercurial. The latter explains why there aren't pipelines running for tags and why it takes a while for the tags to be visible in the "Run pipeline" page. Closes heptadod#260 What happened here is that the tags were correctly exported and this was tested, but it happened before `update_references()`, which is in particular the method that's responsible for sending notifications. Once the tags were written in the Git repo, of course 'update_references()` wouldn't see them. But it's worse than that: `get_exportable()` only inspects heads (all these methods are really ill-named in hg-git). We considered not duplicating `export_hg_tags()` and comparing the tags before and after, but it has the major drawback for us to write immediately to the Git repo, whereas we want to send the `pre-receive` notification to GitLab before writing. Besides, `export_hg_tags()` wasn't so complicated, and our testing is more thorough than in upstream hg-git.
-
Georges Racinet authored
This is a pristine copy as of hg-git 0.9.0a1
-
- May 08, 2020
-
-
Georges Racinet authored
In the `default` branch, we'll use a different version.
-
- May 06, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
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.
-
- May 05, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
For the call to `published_topic_latest_hg_sha` in the case the previous changeset is obsoleted by a public changeset, since we now get `None` if the successor is not on topic, we can avoid checking that condition in advance, to test the `None` return value explicitely without creating dead code. Using a revset for that will be marginally slower.
-
Georges Racinet authored
This condition was an indication of corruption, but refusing the push currently does much more harm than cleaning up the condition, even if the cleanup risks itself to turn out wrong. In the case detailed in heptapod#265, we had a Git repository inconsistency which we could only reproduce manually by forcing the Git branch for the topic: the previously know topic head was both public and not on topic. Getting `None` in the other call to `published_topic_latest_hg_sha` can't happen, but this will have to be refactored for clarity.
-
- May 03, 2020
-
-
Georges Racinet authored
We're going to need to send GitLab hooks from the temporary working directories (shares) that are used in Rails to perform operations. For that, the path to the Git repo must be inferred from the share source path.
-
- Apr 30, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Apr 29, 2020
-
-
Georges Racinet authored
This will be useful for rebase and fold operations from the Rails app. As explained in the docstring, the same result can be obtained with two successive calls to hg log, together with parsing of results to refuse ambiguities. While such a upstream Mercurial or Evolve should provide a template for this, we'll have a much better robustness with this fully tested command. Making the call from Rails the simplest possible has the biggest value for us.
-
Georges Racinet authored
It will also be useful elsewhere
-
- 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.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Feb 17, 2020
-
-
Georges Racinet authored
The easiest part of heptapod#189: since the extension is inert if there is no manifest file, activating it inconditionally won't be a problem.
-
- Apr 18, 2020
-
-
Georges Racinet authored
-
- Apr 05, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
The content is intended to be identical to 0.12.0, but this will allow us to test scenarios with installation from PyPI and correct specific problems with that.
-
Georges Racinet authored
It'd been simply forgotten. In order to avoid that in case of future changes, we switch to the standard `find_packages()`. This has the side effect of including the various tests packages, but that isn't a problem for so small a project, and it might even be a good thing for repackagers (Linux distributions…) that need to launch the tests.
-
- Mar 30, 2020
-
-
Georges Racinet authored
We've just had a GitLab branch named `topic/something` (with no named branch) on foss.heptapod.net, and it blocked all pushes to the affected project. We should probably just prune it, but I feel like not adding any risk we can avoid these days.
-
- Mar 27, 2020
-
-
Georges Racinet authored
This is a new feature in `hg-evolve` 9.3.0. To clients that don't have the topic extension, topics look like multiple draft heads, and create much confusion.
-
- Apr 05, 2020
-
-
Georges Racinet authored
As reported in heptapod#226, repeatedly importing the same changeset rewrites it several time, which is the very definition of content divergence. With these changes, we avoid re-pulling a changeset that's already present, yet obsolete. In the stacked PR use-case, the end result is that the second topic is orphan, but that's a much more frequent and easier to solve condition. We actually already had something for a similar case in the form of `non_obsolete_revs()`, but at the time the scenario of stacked PRs had been thought of only a posteriori, at the time of writing the docstring for the corresponding `test_already_obsolete()`. We could have thinked a bit more here. In truth `non_obsolete_revs()` is probably useless with our solution which is to take obsolete changesets into account in the initial assessment of the pull to be made, and that reflects with it not filtering anything in our existing tests. Since we are on the eve of a major release, we still keep it out of caution, only adding a direct test to restore coverage
-
- Mar 30, 2020
-
-
Georges Racinet authored
-
Georges Racinet authored
This is identical to rc4 for this component, more in phase with package metadata (some of these had been added after the rc4 tag, yet are part of rc4 on PyPI)
-
- Mar 29, 2020
-
-
Georges Racinet authored
See the long description for heptapod-0.8.4, explaining why we decided it to be identical to 0.8.3
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Although at this time we have most of the work done to rewrap hg-git in the heptapod-0-8 branch, it's too risky for release as 0.8.4. We'll just release 0.8.4 as identical to 0.8.3, only including this in a 0.8.5 if 0.12.0 is too much delayed.
-
- Mar 27, 2020
-
-
Georges Racinet authored
-
- Mar 16, 2020
-
-
Georges Racinet authored
also mentioned in the comment that we'll switch later on to a shared secret token.
-