Migration Subversion vers gitlab

Oui, en 2019 certains utilisaient encore Subversion, et il a fallu que j’adapte un peu les documentations de migration vers git pour qu’elles fonctionnent avec git 2. Et j’ai scripté le processus complet (y compris la configuration de gitlab)

Transfert des sources

Cette partie devrait fonctionner avec n’importe quel serveur git. En cherchant sur Internet, on a d’abord trouvé https://gist.github.com/epicserve/1219858 : une procédure assez complète.

Le problème, c’est qu’elle date de 8 ans, et que git est passé de la version 1 à la version 2. Et son comportement par défaut sur les préfixes de branches SVN a changé. Il a donc fallu passer un paramètre supplémentaire --prefix "" lors du git svn clone.

J’ai donc mis à jour ce gist : https://gist.github.com/mossroy/22aebd54133b17e0b70283fd50bb616a, et m’en suis servi pour scripter ces étapes. Voici mon script migrate-svn-to-git.sh, qui fonctionne à la fois sous Git bash (sous Windows) et sur Linux (testé sur CentOS 7) : https://gitlab.com/mossroy/migrate-svn-to-git (voir le README sur comment l’utiliser).

Par rapport au gist, j’y ai ajouté une étape de normalisation des caractères de fin de ligne en LF. Ca m’a paru nécessaire car l’existant que j’ai eu à traiter avait un mix entre CR/LF et LF dans SVN, et que l’utilisation du client git Windows (avec son paramétrage par défaut) allait de toutes façons progressivement convertir (sur le serveur git) tout en LF. On a donc préféré tout passer en LF d’un coup, plutôt que de risquer de mauvaises surprises lors d’un commit quelconque.

Configuration de gitlab via les APIs

Les APIs REST de gitlab sont extrêmement pratiques pour automatiser des choses, et peuvent être un contournement de l’absence de templates de projets dans la version gratuite de Gitlab.

J’ai mis dans https://gitlab.com/mossroy/migrate-svn-to-git un script configure-gitlab-project.sh qui donne un exemple, à adapter à vos propres besoins. En l’occurrence, ce script fait plusieurs choses :

  • Désactiver la gestion des « issues », et activer le « Request access »
  • Protéger la branche master
  • Configurer l’intégration avec un serveur JIRA (en remplacement des issues de gitlab)
  • Optionnellement configurer l’intégration avec un serveur Jenkins (pour qu’une Merge Request lance automatiquement un build sur Jenkins, sur lequel le plugin https://plugins.jenkins.io/github-branch-source doit être installé et configuré : j’y reviendrai probablement dans un autre article)

Il faut prendre ce script comme un point de départ duquel s’inspirer, à modifier en fonction du contexte.

Résultat

Quel bonheur d’avoir enfin toutes les fonctionnalités de git et de gitlab ! Les Merge Requests apportent notamment une bien meilleure souplesse de développement (possibilité simple de décider tardivement de quelles branches seront fusionnées, en les « rebasant » si besoin), une intégration continue qui indique immédiatement si les tests unitaires passent ou pas, et un outillage pour les revues de code qui le rendent bien plus faciles et naturelles. L’interface web très complète permet également aux non-développeurs de consulter les sources, et même de créer des merge requests facilement (sans client git)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *