Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • heptapod heptapod
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 191
    • Issues 191
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

April 05-07 - Mercurial Paris Conference 2023 - One day of workshop dedicated to Heptapod and Mercurial usage and workflow. There are still places available for both workshops and talks!

  • heptapodheptapod
  • heptapodheptapod
  • Issues
  • #689
Closed
Open
Issue created Sep 06, 2022 by Georges Racinet@gracinet🦑Owner5 of 6 checklist items completed5/6 checklist items

Direct conversion from GitLab upstream

The Heptapod Mercurial repositories for the Rails application and Omnibus have always been converted from the upstream Open Source version, a.k.a Community Edition, see theit marketing guidelines for terminology.

Originally, the Community Edition Git repository was upstream of the Enterprise Edition Git repository, but that was changed around version 12.3, with the CE repository relocated and now fed with periodic extracts from the EE repository.

Heptapod kept on converting from the CE repository, with the ill effects described in #594 (bearable) and worse, a garbled ancestry of release branches: instead of having a release (x-y-stable) branch starting over every month from the trunk, they are artifically stacked on top of each other. This causes artificial conflicts when trying to merge upstream changes in Heptapod in advance of the actual releases, and prevents us from following upstream continuously.

We should therefore convert/import directly from the true upstream, implementing ourselves the removal of the EE code, that we obviously haven't rights to redistribute.

Also, rebasing Heptapod on (a conversion of) the upstream trunk would pave the road for semi-automatic update from upstream (automatic merge performed by CI if tests pass).

Task list:

  • rebase of the Heptapod development branch onto a changeset equivalent to the conversion of the gca of upstream EE main branch and the 14-10-stable branch (called below the 14.10 branching point. The corresponding Git commit does not really exist in gitlab-foss. We don't want to convert again ancestors of the branching point, because
    1. we already have the code, and don't want to create more than 200 000 changesets for no purpose
    2. in versions prior to 12.3, there is no reason for the EE code to be in the same separate directories as it is currently. Cutting at 12.3 would be no simpler than at 14.10.
  • patched hg-git able to produce the same results as the GitLab exporter of EE to CE
  • direct import of the Git EE commits that are not descendents of the branching point but are ancestors of the upstream trunk (branches started before the branching point and merged after, dubbed anterior merged ramifications). This is necessary to prevent hg-git importing the whole repository. A fixed list is good enough for the time being. As we are about 2 months after the 14.10 EOL, chances are that no new anterior merged ramifications will appear (contributors being probably asked to rebase on a current commit).
  • automated validation: a script to check the release tags we get at the end of the process should have the exact same content as in the gitlab-foss upstream repository (we cannot compare intermediate commits). It would be safer to leave the converted changesets in the draft phase until there is a tagged release to compare, but that has strong implications on the development workflow (non-publishing MRs, which are not currently available in Heptapod).
  • at least a way to guard against importing ancestors of the branching point (will happen if a new anterior merged ramification appears)
  • continuous operation, using the patched hg-git and the automated validation above.

Continuous merge of upstream in Heptapod would be another issue.

Edited Feb 14, 2023 by Georges Racinet
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking