Since the beginning of the Heptapod project, the inner changes we've made to support Mercurial have been actually modifications to the
Since then (from GitLab 10.5 to 12.3), lots has happened:
Repositoryclass has become upstream essentially a forwarder to Gitaly client classes
- we've moved our modifications into distinct methods (usually prefixed in
- we've introduced the
vcs_typefield on the Project model, had the various callers use it to dispatch to the appropriate methods.
At the point reached in Heptapod 0.12, we had a form of inner VCS independency (dual VCS support being a long term goal), but it was spread over.
This MR introduces the new
Gitlab::Mercurial::HgGitRepository class, and use a classical factory pattern in the
Repository model to dispatch according to the value of
vcs_type, making many - but not all - calls effectively transparent for the callers.
At this point we can have a better confidence that Git code paths are untouched, which is essential for dual VCS support as well as for the introduction of HGitaly backed repositories, that don't rely on Git at all.
At the end of the series:
- the diff with upstream GitLab for
Gitlab::Git::Repositoryboils down to accepting (and ignoring) optional arguments in the
Gitlab::Shell(remnant of ancient times when operations on a repository as a whole where actually handled by GitLab Shell), the
createmethod simply defers to the
Repositorymodel, slightly ahead of GitLab 12.3, and like it will in Gitlab 12.4
After this, there would still be some work to be done in
Gitlab::Shell, to make repository moves (used in particular by the hash storage migration and rollback) and imports dispatch, but that's too much for Heptapod 0.13.0rc1