- Apr 25, 2021
-
-
Georges Racinet authored
The parsing of subrepos provides now more information than just the (qualified) local path if accessed with `parsed[section]`. Since our goal is (at this point) to refuse lots of operations on subrepos, ignoring the new information will be good enough for now, and that is what `parsed.items` does (returning a list of pairs).
-
Georges Racinet authored
We'll need to run code depending of Mercurial version for 5.8
-
Georges Racinet authored
hg-git 0.11 drops support for Python 2, and as a result, does not rewrap `OrderedDict` anymore. Since py-heptapod dropped Python 2 a while ago, we can import from `collections` directly.
-
- May 12, 2021
-
-
Georges Racinet authored
This means that the `.only_py_heptapod_default` now means "and not triggered from upstream hg-git pipelines.
-
Georges Racinet authored
The key is to accept a new variable for the upstream revision. In turn this means that the previous "default" has to be handled in the install script. Since it the existence of a revision was used to decide whether to pull/update, we now have to use a new variable for that.
-
- Apr 15, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
WSGI: avoid leaking repository class objects See merge request !60
-
- Apr 03, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Apr 15, 2021
-
-
Georges Racinet authored
This is the same as hgitaly!59, except that we can be confident that we aren't serving a repo that was created by `hg share`. Mutualization of some kind would obviously be beneficial, but is prematurate, depending on what we can do upstream (Mercurial or topic extension).
-
- Apr 03, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Previously, the detection of tags removal was based on back-converting to Mercurial the existing GitLab tags, which cannot work in case of escaped names. Instead, we perform the detection entirely on the GitLab side. We can still have collisions, but there's not much that can be done about it (except that publication rights will be necessary to actually change a GitLab tag due to such a collision). We also make it clear in the case the user does not have sufficient permissions that the reported tag name is the GitLab one, and can be slightly different from the Mercurial one. Closes heptapod#464 (see there for the bad consequences)
-
- Apr 02, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
It was specified as for the stable branch. Stronger pinning occurs in Heptapod main repository anyway.
-
- Apr 01, 2021
-
-
Georges Racinet authored
The stable branch will be released as 2.5.0, hence we need the future version in the default branch to be 2.6
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
We've been using hg-evolve 10.2 for a while but never got to update the dependency. Current pip version will insist on the conflict avoidance, and that is obviously a good thing.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
The changes are big enough in py-heptapod to warrant more than a patch version change, even though from the point of view of Heptapod as a whole, they are merely bugfixes. Will also bump the future version in default branch to 2.6
-
Georges Racinet authored
Closes heptapod#451
-
Georges Racinet authored
Really needed in case testing code has to perform two operation on tags without reloading.
-
Georges Racinet authored
This is easier to import and use from other parts of the code base. Also noted a few TODOs to make things cleaner, but the new function does all the hiding for external callers.
-
Georges Racinet authored
- `self.repo` weariness - use `gitlab_tag_ref()`. If ever this becomes a performance problem in this busy loop because Python function calls are expensive, we could play the Rust trump card, but we have much more obvious bottlenecks for now.
-
- Mar 22, 2021
-
-
Georges Racinet authored
We have a general protection against making tag targets obsolete, but it was seeing tags that are themselves obsolete, hence preventing the legitimate case of obsoleting both, so we need to recheck, using the original (filtered) repository. In many cases, it is not so easy to have a tag in the filtered repository that points to an obsolete changeset: normally Mercurial would just ignore the tag in that case, but it can happen if the obsolete changeset is still visible (e.g, if it has children). This is now used by the test case for the protection, once we do the rechecking on filtered tags. Closes: heptapod#432
-
- Mar 21, 2021
-
-
Georges Racinet authored
Closes heptapod#448
-
- Mar 20, 2021
-
-
Georges Racinet authored
-