Découvrez comment migrer de Subversion (SVN) vers Git, y compris l’historique

  • Article

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Lorsque vous passez à Git à partir d’un autre système de contrôle de version comme Subversion (SVN), nous vous recommandons généralement d’effectuer une « migration tip », qui migre uniquement la dernière version du contenu du référentiel, sans inclure d’historique. Toutefois, de nombreuses personnes souhaitent effectuer une migration plus avancée, y compris l’historique. Les conseils fournis dans cet article présentent une migration avec historique.

Les migrations SVN vers Git peuvent varier en complexité, selon l’ancienneté du référentiel et le nombre de branches créées et fusionnées, et selon que vous utilisez SVN standard ou un parent proche comme SVK.

Il peut être simple si :

  • Vous disposez d’un nouveau référentiel
  • Vous disposez d’une configuration standard d’un répertoire de jonction, de branches et d’étiquettes

Il sera probablement complexe si :

  • Votre équipe a effectué de nombreuses opérations de branchement et de fusion
  • Votre référentiel suit une configuration de répertoire non standard
  • La configuration de votre répertoire a changé au fil du temps

Il existe plusieurs façons de migrer de SVN vers Git. L’approche décrite dans cet article est basée sur l’utilisation de git-svn, une extension Git, qui peut être utilisée pour extraire un dépôt Subversion vers un référentiel Git local, puis envoyer (push) les modifications du référentiel Git local vers le référentiel Subversion. Ces étapes donnent une vue d’ensemble détaillée du processus de migration de SVN vers Git dans un environnement Windows, sans effectuer la synchronisation avec le référentiel SVN d’origine. Le résultat sera un référentiel Git complet pour le partage avec le reste de votre équipe.

Notes

Avant d’essayer de migrer votre code source d’un système de contrôle de version centralisé vers Git, veillez à vous familiariser avec les différences entre les systèmes de contrôle de version centralisés et distribués et à planifier la migration de votre équipe. Une fois que vous avez préparé, vous pouvez commencer la migration.

Le flux de travail de haut niveau pour la migration de SVN vers Git est le suivant :

  • Préparer un environnement de migration
  • Convertir le référentiel SVN source en référentiel Git local
  • (Facultatif) Synchroniser le référentiel Git local avec toutes les modifications du référentiel SVN pendant que les développeurs continuent à utiliser SVN
  • Envoyer (push) le référentiel Git local vers un référentiel Git distant hébergé sur Azure Repos
  • Verrouiller le référentiel SVN, synchroniser les modifications restantes du référentiel SVN vers le référentiel Git local et envoyer (push) les modifications finales vers le référentiel Git distant sur Azure Repos
  • Les développeurs basculent vers Git en tant que système de contrôle de code source principal

Préparer un environnement de migration

Configurez un environnement de migration sur une station de travail locale et installez les logiciels suivants :

Vous devrez également créer un référentiel Git pour votre organisation afin d’héberger le référentiel SVN converti, vous pouvez suivre Créer un dépôt Git dans votre projet

Convertir le référentiel SVN source en référentiel Git local

L’objectif de cette étape est de convertir le référentiel Subversion source en référentiel Git nu local. Un référentiel Git nu n’a pas d’extraction opérationnelle locale des fichiers qui peuvent être modifiés, mais il contient uniquement l’historique du référentiel et les métadonnées relatives au référentiel lui-même. Il s’agit du format recommandé pour le partage d’un référentiel Git via un référentiel distant hébergé sur un service tel qu’Azure Repos.

Conseil

Les référentiels Git nus sont structurés différemment et étant donné le fait qu’il n’a pas de répertoire de travail, ils empêchent la validation directe dans le référentiel.

Référentiel Git nu

Récupérer une liste de tous les auteurs Subversion

Subversion utilise simplement le nom d’utilisateur pour chaque validation, tandis que Git stocke à la fois un nom réel et une adresse e-mail. Par défaut, l’outil git-svn répertorie le nom d’utilisateur SVN dans les champs auteur et e-mail. Toutefois, vous pouvez créer un fichier de mappage pour les utilisateurs SVN, ainsi que leurs noms Git et e-mails correspondants.

Utilisateurs Subversion

Utilisateurs Subversion

Utilisateurs Git

Utilisateurs Git

Pour extraire la liste de tous les utilisateurs SVN de la racine de votre extraction Subversion locale, exécutez cette commande PowerShell :

svn.exe log --quiet | ? { $_ -notlike '-*' } | % { "{0} = {0} <{0}>" -f ($_ -split ' \| ')[1] } | Select-Object -Unique | Sort-Object | Out-File 'authors-transform.txt' -Encoding utf8NoBOM

Cette commande récupère tous les messages de journal, extrait les noms d’utilisateur, élimine les noms d’utilisateur en double, trie les noms d’utilisateur et les place dans un fichier authors-transform.txt au format UTF-8. Vous pouvez ensuite modifier chaque ligne du fichier pour créer un mappage d’utilisateurs SVN à des utilisateurs Git bien formatés. Par exemple, vous pouvez mapper jamal = jamal <jamal> à jamal = Jamal Hartnett <jamal@fabrikam-fiber.com>.

Cloner le référentiel Subversion à l’aide de git-svn

La commande suivante effectue la transformation git-svn standard à l’aide du fichier authors-transform.txt créé à l’étape précédente. Il place le référentiel Git dans le dossier c:\mytempdir dans votre ordinateur local.

git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --authors-file "authors-transform.txt" --stdlayout c:\mytempdir

Notes

Le --prefix=svn/ est nécessaire, car sinon, les outils ne peuvent pas indiquer les révisions SVN à partir de celles importées. Nous vous recommandons de définir un préfixe (avec une barre oblique de fin), car vos références de suivi SVN se trouvent ensuite à refs/remotes/$prefix/, qui est compatible avec la disposition de la branche de suivi à distance de Git (refs/remotes/$remote/).

La définition d’un préfixe est également utile si vous souhaitez suivre plusieurs projets qui partagent un référentiel commun. Par défaut, le préfixe est défini sur origin/.

Si vous utilisez la disposition de jonction, de branches et d’étiquettes standard, utilisez simplement --stdlayout. Cependant, si vous avez quelque chose de différent, vous devrez peut-être passer --trunk, --branches, et --tags pour savoir ce qu'il en est. Par exemple, si votre structure de référentiel était trunk/companydir et que vous l’avez ramifiée au lieu de la joindre, vous souhaiteriez probablement --trunk=trunk/companydir --branches=branches.

git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --trunk=/trunk --branches=/branches --tags=/tags  --authors-file "authors-transform.txt" c:\mytempdir

Notes

Cette commande peut prendre quelques minutes à plusieurs heures en fonction de la taille du référentiel SVN. Une fois l’opération terminée, vous disposez d’une extraction Git de votre référentiel.

Convertir des configurations spécifiques au contrôle de version

Si votre référentiel SVN utilisait les propriétés svn:ignore, vous pouvez effectuer une conversion en fichier .gitignore à l’aide de :

cd c:\mytempdir
git svn show-ignore --id=origin/trunk > .gitignore
git add .gitignore
git commit -m 'Convert svn:ignore properties to .gitignore.'

Conseil

En savoir plus sur .gitignore : Ignorer les modifications de fichier avec Git

Envoyer (push) un référentiel vers un référentiel Git nu

Dans cette étape, vous allez créer un référentiel nu et faire correspondre sa branche par défaut au nom de la branche de jonction SVN.

  1. Créer un référentiel Git nu

    git init --bare c:\new-bare.git
cd c:\new-bare.git
git symbolic-ref HEAD refs/heads/svn/trunk

  2. Envoyer (push) le référentiel Git local vers le nouveau référentiel Git nu

    cd c:\mytempdir 
git remote add bare c:\new-bare.git 
git config remote.bare.push refs/remotes/*:refs/heads/* 
git push bare

  3. Renommez la branche trunk en main. Votre branche de développement principale sera nommée « trunk », qui correspond au nom qu’elle avait dans Subversion. Vous devrez la renommer en branche standard main de Git en utilisant :

    cd c:\new-bare.git
git branch -m svn/trunk main

  4. Nettoyer les branches et les balises git-svn rend toutes les balises Subversions en branches très courtes dans Git sous la forme « tags/name ». Vous devez convertir toutes ces branches en balises Git réelles ou les supprimer.

Migrer des balises SVN pour qu’elles soient des balises Git

cd c:\new-bare.git
git for-each-ref --format='%(refname)' refs/heads/svn/tags | % { $_.Replace('refs/heads/svn/tags/','') } | % { git tag $_ "refs/heads/svn/tags/$_"; git branch -D "svn/tags/$_" }

Migrations avancées

Créer toutes les branches SVN en tant que branches Git appropriées

Bien qu’il soit facile de créer toutes les branches SVN en tant que branches Git appropriées, il est recommandé d’évaluer les points suivants avant de continuer :

  • S’il existe des branches de fonctionnalité : pouvez-vous attendre qu’elles s’intègrent au tronc avant de migrer ?

  • S’il existe des branches de mise en production : est-il judicieux de conserver SVN pour la maintenance ? Si vous migrez des branches de fonctionnalités, êtes-vous prêt à traiter des branches hors de Git ?

Si vous souhaitez toujours migrer des branches existantes, exécutez la commande PowerShell suivante :

git for-each-ref --format='%(refname)' refs/remotes | % { $_.Replace('refs/remotes/','') } | % { git branch "$_" "refs/remotes/$_"; git branch -r -d "$_"; }

Notes

Cette commande peut prendre quelques minutes à plusieurs heures en fonction de la taille du référentiel SVN. Une fois l’opération terminée, vous disposez d’une extraction Git de votre référentiel.

Migrer uniquement des révisions spécifiques

Lorsqu’elle n’est pas spécifiée, git-svn clone migre toutes les révisions de la première validation (r1) vers HEAD. Si vous devez migrer uniquement un ensemble spécifique de révisions, la commande pour git-svn clone doit être ajoutée avec une option de -r.

Par exemple, si vous devez migrer de rev 100 vers HEAD, la commande ressemble à ceci :

git svn clone ["SVN repo URL"] --prefix=svn/ --no-metadata --authors-file "authors-transform.txt" --stdlayout c:\mytempdir -r100:HEAD

Mettre à jour votre flux de travail

Le passage d’un système de contrôle de version centralisé à Git ne consiste pas seulement à migrer du code. Votre équipe a besoin d’une formation pour comprendre en quoi Git est différent de votre système de contrôle de version existant et comment ces différences affectent le travail quotidien. Plus d’informations

Informations de référence

Auteurs : Hosam Kamel, William H. Salazar | Recherchez l’origine de cet article et connectez-vous à l’ALM | Conseils de création de branches DevOps Rangers

(c) 2017 Microsoft Corporation. Tous droits réservés. Ce document est fourni « comme tel ». Les informations et opinions exprimées dans ce document, y compris les URL et autres références à des sites Internet Web, peuvent changer sans préavis. Vous assumez les risques liés à leur utilisation.

Ce document ne vous fournit aucun droit légal de propriété intellectuelle de tout produit Microsoft. Vous pouvez copier et utiliser ce document pour votre information uniquement.