- Apr 02, 2021
-
-
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
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
-
- Mar 19, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
Heptapod 0.20 is now the new stable.
-
- Mar 12, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
- Mar 11, 2021
-
-
Georges Racinet authored
This takes care of all configuration and state files that should be routinely backuped for Heptapod. Rather than painfully maintaining correspondence in the Rails application by spawning a `tar` executable, it is much better to use the various constants we have around in py-heptapod, and it is a much easier setup for comprehensive testing than in the Rails app. We also have functional tests to confirm at the opposite of the spectrum.
-
Georges Racinet authored
In particular, no need to include `py3` in them anymore.
-
Georges Racinet authored
Same as done earlier today in HGitaly
-
Georges Racinet authored
All other such file names take the plural form
-
Georges Racinet authored
This `special-refs` can seem to be redundant in context within Python code, but it's much better to have a `gitlab.special-refs` on disk than the obscure `gitlab.special`
-
- Mar 10, 2021
-
-
Georges Racinet authored
I don't feel the need to create a tag for 2.4.0dev0. It's just to make it easy for developpers until 2.4.0 itself gets released (should be tomorrow or the day after)
-
Georges Racinet authored
Each individual ensuring method now returns the content just stored (or `None` if nothing happened). This is nicer to downstream readers, such as HGitaly: they can call ensure after detection of missing file and used the returned collection directly.
-
- Mar 09, 2021
-
-
Georges Racinet authored
The introduction of state files for tags, special refs and keep-arounds is well worth a minor version bump.
-
Georges Racinet authored
also part of ensure_all_gitlab_refs, which is the command that GitLab backups should call before starting to extract data.
-
Georges Racinet authored
-
Georges Racinet authored
Basic facilities, no method to ensure the state file presence yet. We reuse some of the infrastructure for other typed refs, but we use a simpler file format.
-
Georges Racinet authored
We don't feel a strong need to split it into branches and tags. Special refs already have their own test module.
-
Georges Racinet authored
It was simply renamed earlier. Downstream packages, such as HGitaly may still use it, that's why we keep a compatibility alias.
-
Georges Racinet authored
This code started out for branches only, then it became more generic to introduce tags and later, special refs, while staying in the `branch` module. It is time for proper separation. We'll split the tests as needed in a follow-up move.
-
Georges Racinet authored
The default behaviour is to ignore them.
-
Georges Racinet authored
Also, a clearer way of excluding irrelevant refs for a given extraction method. Performance-wise, probably less effecting than discarding ``None`` after the fact, but it also avoids a needless conversion to Mercurial SHA for irrelevant refs. More important is the possibility to define fallback options.
-
- Mar 08, 2021
-
-
Georges Racinet authored
Could be useful in migration scenarios.
-
Georges Racinet authored
Like the ones for branches and special refs, it was missing. The main use case would be manual reconstruction by a human operator.
-
- Mar 07, 2021
-
-
Georges Racinet authored
This is provided as a CLI command and an easy to import function. The decision to ensure the state file from the Git repository should not belong to py-heptapod, but either to an operator fixing inconsistencies or to HGitaly. All currently existing refs on native Mercurial repositories are Merge Request heads: no other ref could have worked, because `WriteRef` is currently refusing to do anything else than setting the default branch. Still, we have the possiblity of corruption with the same TODO as for branches and tags.
-
- Mar 10, 2021
-
-
Georges Racinet authored
will be useful for forthcoming testing of synchronizing code for special refs.
-
- Mar 06, 2021
-
-
Georges Racinet authored
Part of heptapod#431. This doesn't provide a callable to initialize the special refs file from the Git repository refs yet. We found it acceptable to use a single file for all these special refs, but we decided to exlude keep-arounds for the reason stated in the docstring for the `SPECIAL_REFS` constant. We've considered using local Mercurial tags, but we finally preferred to reuse our own logic for GitLab state files. Reasons: - local tags are not exposed as 1st class citizens in the internal API, everything is meant to add them to global tags for exposition in `hg tags`. - with local tags, we'd have to perform additional namespacing to prevent confusion and would still be at risk of confusion (or even attack by masking with a global tag?) - the unneeded complexity for our use case in Mercurial local tags is such that it took us less time to implement the whole write and read logic on the py-heptapod primitive, with complete tests than to be reasonably sure of how local tags really behave (cache invalidation etc.) - uniformity of py-heptapod/HGitaly formats.
-
- Mar 08, 2021
-
-
Georges Racinet authored
We need to flush these ref matters as soon as possible, now.
-
- Feb 25, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-