The software project repository contains code, in a DVCS. But there are other essential information that are not stored with the code:
- issues (description and discussions)
- roadmaps and milestones
- merge/pull requests
- CI/CD configuration and artifacts (i.e. the output of a CI/CD configuration run)
- release artifacts (i.e. not the tags, the tarbals etc.)
- mailing list or discussion forum
- infrastructure hosting the software project (e.g. Enough GitLab playbooks which can create the GitLab instance that is able to run the Enough CI)
- … and more
Given (i) the various of forges (GitLab, Gitea, GitHub, SourceForge) with a large variety of features, (ii) some features are not implemented as Free Software, it will be years before a standard emerges and a custom data model such as the GitLab import/export model must be used in the meantime.
It is convenient to store this data in the same repository as the code, in the same way Fossil does. For git, it could be in an orphan branch that does not share any history with the code.
For GitLab it could be:
- export the GitLab project
- commit the result in the dedicated branch
If this is done every time something changes in the project, each commit represents an individual action (issue created, commented etc.).