Repository migration to native Mercurial VCS type
The only differences in persistent data outside of the repository between hg-git based and native Mercurial repositories are the commit hashes and the vcs_type
field.
While the latter is very easy to update, there are many places that reference commit hashes in the database:
-
Issues and Merge Requests: description
andtitle
columns and their_html
derivatives (stored renderings) -
Comments on Issues, Merge Requests and other (common model that's called Note) -
Merge Requests: several _sha
columns inmerge_requests
andmerge_request_diffs
-
Diff cache on filesystem or object storage (hoping a simple invalidation would be enough) -
Releases: sha
column, or tag (fallback if no sha)
Mandatory tasks for the repository itself:
-
#500 (closed) ensure default GitLab branch file -
ensure all refs from Git using the command provided by py-heptapod!52 (merged). See also #431 (closed)
Entry points
-
library module or class -
rake task to migrate one project, as idempotent as possible, with a FORCE
option to re-run on an already migrated repo.
The list of direct Git SHA references will probably have to grow when we start digging into this for good.
There are many columns named sha
in the database schema. I currently count 35 of them with a crude search:
grep -E 'sha[1|2 ].*(bytea|char|text)' structure.sql | wc -l
35
Also, there is an ActiveRecord sha
attribute type, backed by binary (bytea
) columns. Systematic search for this type could give us more hits.
Work can start in the Heptapod 0.20.0 time frame, but it's likely to be complete only afterwards.