- 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
-
- Feb 23, 2021
-
-
Georges Racinet authored
With the given defaults settings, clients won't see any difference. hg-configexpress 0.4.0 passes all tests with Mercurial 5.6, the series we're using in current Heptapod. The question of how to configure selected projects is entirely open. For now, users have to modify the repo (or group) HGRCs on the server file system. Since there are auxiliary files, the question of backuping them is also open. Closes heptapod#190
-
- Feb 15, 2021
-
-
Georges Racinet authored
At this point, we can send the appropriate pre- and post-receive notifications to GitLab about tags. To help with transition, there is a utility to ensure existence of the state file.
-
Georges Racinet authored
At this point we have the tags state file, but it's not in use yet.
-
Georges Racinet authored
We will have to track tags to support pre-/post-receive notifications to GitLab in fully native repos. We've been pondering about that a bit, as it could be simpler to just store all refs. In truth, we may later also have to store special refs such as Merge Requests and keeparounds, although these are bad examples because Mercurial should not need them. In the end the different update profiles and the fact that changed tags don't seem to be easily available from the transaction object made us go the way of two distinct files. The "typed ref" terminology got adopted because we've seen Git man pages use it. We speak of "short names" because usually "ref" can either mean the general concept or the name of a ref (for instance, branches are refs as concepts but branch names aren't ref names). Of course, much of the read/write/cache logic could be and have been factorized. Now it's a bit weird for it to lie in a `branch` module, we should rename it at some point to `ref` or `typed_ref`.
-
- Feb 14, 2021
-
-
Georges Racinet authored
-
- Feb 13, 2021
-
-
Georges Racinet authored
This is good common practice, and also reflects in this case that major refactorings are on their way.
-
- Jan 29, 2021
-
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
The motivation for this setting is to allow "semi-linear" merge methods, but it uses internally the future `//`, which py-heptapod cannot cope with currently in non-merge cases. For the time being, we'll have the Rails application use that setting only to perform semi-linear merges.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
- Jan 28, 2021
-
-
Raphaël Gomès authored
This will make the 'semi-linear' MR workflow possible.
-
Raphaël Gomès authored
We will be using new config options only available from this version up.
-
- Jan 23, 2021
-
-
Georges Racinet authored
Same as `gitlab_branch_from_ref()` for tags.
-
Georges Racinet authored
and renamed as `update_gitlab_references()`, together with renaming of `get_exportable()` in its abstract form as `extract_all_gitlab_refs()`
-
Georges Racinet authored
It looked scary a while ago, but it has no adherence to Git. Of course, the little dance to convert back to Mercurial SHAs on native repos will be simplified as soon as we introduce the subclass for these.
-
Georges Racinet authored
With a last few conversions from `map_{git,hg}_get` and more direct imports from tests.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
The new `gitlab_refs` attribute makes `heptapod_apply_changes()`, `update_default_gitlab_branch()` applicable outside of hg-git context. For fully native Mercurial projects, we'd simply initialize it with an initial read of the GitLab branches state file. The only catch is that we have to be class-neutral in the final conversion to `dict` for serialization of the GitLab branches state file (needed because `self.git.refs` does not implement `items()`). `gitlab_branches_hg_shas` now takes responsibility for that, for better encapsulation.
-
Georges Racinet authored
-
- Jan 22, 2021
-
-
Georges Racinet authored
Only the actual initial call to the `get_exportable()` of the parent class was actually Git specific. We just update the terminology slightly (easier to track here than with the subsequent move to common code). Side remark: all of this means that we're going to reuse Dulwich `heads_tags` class even for Mercurial repos. It's not really shocking. When that becomes an impediment (e.g., because we don't want to keep the mandatory Dulwich dependency) we can reimplement it or just refactor enough that we don't need it any more.
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
-
Georges Racinet authored
Most of them had the british "analyse" spelling, so we make it the standard. Of course many unrelated methods have US spelling, c'est la vie.
-
Georges Racinet authored
Had to update the monkey-patching in test_inner because we're doing it at instance level, hence without effect on the method that's aliased at the class level: the instance level with the alias is never called.
-
Georges Racinet authored
-
Georges Racinet authored
This is pure Mercurial logic, nothing to adapt
-