- Mar 11, 2021
-
-
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
-
- 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.
-