- Jun 05, 2021
-
-
Georges Racinet authored
-
- May 31, 2021
-
-
Georges Racinet authored
This is enough to launch functional tests and more generally experiment on development instances, but must not come near a production server, as it is essentially an infinitely growing cache.
-
Georges Racinet authored
This is the main cache logic, based on the previously introduced "mutation id" primitives. clear_repo_classes() and its usage in the instance reclaim hook are taken from heptapod.wsgi, where they have been introduced to avoid a memory leak.
-
Georges Racinet authored
Since we're about to introduce a repository instance cache, whose invalidation will be tied on store lock acquire/release, it is necessary for all tests that will use this cache (HGitaly gRPC tests notably) that operations from the test helpers also acquire the lock. As the comment says, this should actually have been the default, but we need to exert some caution and we need it right away.
-
Georges Racinet authored
Closes #10 All writes to the repository store should be protected by `repo.lock()`. This change makes it so that a new mutation id, as previously introduced gets written upon lock release. This is enough for a caching mechanism to perform invalidations
-
Georges Racinet authored
This introduces a new file in the Mercurial store, whose purpose will be to change at each mutation of the store contents, so that a cache invalidation logic can be based on its value.
-
- May 14, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Closes heptapod#479 This assertion reproduces the issue, but the fix is provided by our earlier switch to our own `util.format_shas`, the problem being due to `scmutil.nodesummaries` expecting binary node ids (with no way to tell from the type)
-
Georges Racinet authored
`scmutil.nodesummaries` accepts binary nodes only (not a type error because everything is bytes in Mercurial) and does not fully work with sets. Closes heptapod#441
-
- May 13, 2021
-
-
Georges Racinet authored
It wouldn't run on the specified hg-git revision anyway. Also, HGitaly is not supposed to depend directly on hg-git, but at most on rewrapped py-heptapod functions, which are supposed to be fully tested (enough to be confident about clear API breakage).
-
Georges Racinet authored
The whole system seems mature enough to do this, and it can provide some early protections if we break the API. If we have serious reasons to regret it, we can still disable it temporarily. (done on the stablest branch so that it will propagate nicely up to default)
-
- Apr 25, 2021
-
-
Georges Racinet authored
The signature of the `pull` command changed from ``` def pull(ui, repo, source, **opts) ``` to ``` def pull(ui, repo, *sources, **opts) ``` As a result, it's not possible to use the named argument style for the source any more, but we can still pass it as an anonymous positional argument. It's a bit less explicit, but it works for all versions. (same thing with `push`)
-
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 24, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- 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
-