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

  • Article
  • 8 minutes de lecture

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

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 de conseils », qui migre uniquement la dernière version du contenu du dépôt, 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 dépôt et le nombre de branches créées et fusionnées, et selon que vous utilisez SVN standard ou un parent proche comme SVK.

Cela peut être simple si :

  • Vous disposez d’un nouveau dépôt
  • Vous disposez d’une configuration standard d’un répertoire de jonction, de branches et de balises

Cela sera probablement complexe si :

  • Votre équipe a effectué de nombreuses opérations de branchement et de fusion
  • Votre dépôt suit une configuration d’annuaire 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 dépôt Git local, puis envoyer les modifications du dépôt Git local au dépôt 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 dépôt SVN d’origine. Le résultat sera un dépôt Git nu 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 dépôt Git local avec les modifications apportées au référentiel SVN pendant que les développeurs continuent d’utiliser SVN
  • Push du dépôt Git local vers un dépôt Git distant hébergé sur Azure Repos
  • Verrouillez le dépôt SVN, synchronisez toutes les modifications restantes du dépôt SVN vers le dépôt Git local et envoyez les modifications finales au dépôt Git distant sur Azure Repos
  • Les développeurs basculent vers Git comme 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 dépôt Git pour votre organisation afin d’héberger le dépôt 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 dépôt Subversion source en un dépôt Git nu local. Un dépôt Git nu n’a pas d’extraction opérationnelle locale des fichiers qui peuvent être modifiés, mais il contient uniquement l’historique du dépôt et les métadonnées relatives au dépôt lui-même. Il s’agit du format recommandé pour le partage d’un dépôt Git via un dépôt distant hébergé sur un service comme Azure Repos.

Conseil

Nu Les dépôts Git sont structurés différemment et étant donné qu’ils n’ont pas de répertoire de travail, ce qui empêche la validation directe sur le dépôt.

Dépôt Git nu

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

Subversion utilise simplement le nom d’utilisateur pour chaque commit, 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 utf8

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 dépôt 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 dépôt Git dans le c:\mytempdir dossier de 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, vous allez simplement mettre --stdlayout. Toutefois, si vous avez quelque chose de différent, vous devrez peut-être passer le --trunk, --brancheset --tags pour trouver ce qui est quoi. Par exemple, si votre structure de dépôt était trunk/companydir et que vous l’avez ramifiée au lieu de jonction, vous souhaiteriez --trunk=trunk/companydir --branches=branchesprobablement .

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 dépôt SVN. Une fois terminé, vous aurez une extraction Git de votre dépôt.

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 convertir en fichier .gitignore à l’aide de :

cd c:\mytempdir
git svn show-ignore > .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

Dépôt push vers un dépôt Git nu

Dans cette étape, vous allez créer un dépôt nu et faire en sorte que sa branche par défaut corresponde au nom de branche de jonction de SVN.

  1. Créer un dépôt 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 dépôt Git local vers le nouveau dépôt 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 trunk branche en main. Votre branche de développement principale sera nommée « trunk », ce qui correspond au nom qu’elle portait dans Subversion. Vous devez le renommer en branche standard main de Git à l’aide de :

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

  4. Nettoyer les branches et les étiquettes git-svn transforme 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 vers 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 dépôt SVN. Une fois terminé, vous aurez une extraction Git de votre dépôt.

Migrer uniquement des révisions spécifiques

Lorsqu’elle n’est pas spécifiée, git-svn clone migre toutes les révisions du premier commit (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 se présente comme suit :

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

Mettre à jour votre workflow

Le passage d’un système de contrôle de version centralisé à Git ne se limite pas à la simple migration de 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 à alm | Conseils de création de branches DevOps Rangers

(c) 2017 Microsoft Corporation. Tous droits réservés. Ce document est fourni « tel qu’il est ». Les informations et les vues exprimées dans ce document, y compris l’URL et d’autres références de site Web Internet, 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 le présent document pour une utilisation interne à des fins de référence.