Partager via

Migrer à partir de Visual SourceSafe

  • Article

Vous pouvez utiliser l'outil en ligne de commande VSSConverter de Team Foundation pour effectuer une migration des projets, des fichiers, de l'historique des versions, des étiquettes et des informations utilisateur de votre base de données Visual SourceSafe vers votre serveur de contrôle de version Team Foundation. Cet outil est inclus dans Visual Studio Team Foundation Server.

Pour plus d'informations sur Visual SourceSafe, consultez la page suivante sur le site Web Microsoft : Contrôle de code source pour Visual Studio (page éventuellement en anglais).

Pour migrer des données à partir de votre base de données Visual SourceSafe

  1. **Assimilez les concepts clés.   **Avant d'effectuer une migration des données de votre base de données Visual SourceSafe vers votre serveur de contrôle de version Team Foundation, vous devez comprendre certains concepts clés. Team Foundation et Visual SourceSafe présentent des différences fonctionnelles significatives. Par conséquent, VSSConverter doit modifier certains genres de données lors de leur migration.

    Pour plus d'informations, consultez Comment VSSConverter convertit vos données plus loin dans cette rubrique.

  2. **Vérifiez que vous disposez des autorisations requises.   **Pour effectuer les procédures de cette rubrique, vous devez disposer de plusieurs types d'autorisations. Pour plus d'informations, consultez Autorisations requises plus loin dans cette rubrique.

  3. **Planifiez et préparez le processus de migration.   **Avant de débuter le processus de migration, suivez les étapes de planification et de préparation appropriées pour éviter, vous et votre équipe, d'être confrontés à des problèmes graves. Pour plus d'informations, consultez Planifier et préparer le processus de migration plus loin dans cette rubrique.

  4. **Analysez vos données.   **Avant d'effectuer une migration de vos données de Visual SourceSafe vers le contrôle de version Team Foundation, vous devez utiliser au préalable la fonctionnalité d'analyse du convertisseur Visual SourceSafe pour déterminer si les éventuels problèmes relatifs à vos données peuvent affecter le résultat de la migration. Ce processus génère également un fichier de mappage utilisateur qui est indispensable à la migration de vos données. Pour plus d'informations, consultez Analyser vos données plus loin dans cette rubrique.

  5. **Migrez vos données.   **Après avoir exécuté la fonctionnalité d'analyse, vous êtes quasiment prêt à migrer vos données. Pour migrer vos données, vous devez spécifier la façon dont les noms d'utilisateurs sont migrés, créer un fichier de paramètres de migration, puis exécuter la commande Migrate. Pour plus d'informations, consultez Migrer vos données plus loin dans cette rubrique.

  6. **Vérifiez la migration et résolvez les problèmes.   **Une fois l'exécution de la fonctionnalité de migration achevée, vous devez effectuer les étapes suivantes :

    • Passez en revue le rapport généré par la fonctionnalité de migration.

    • Vérifiez les données sur votre serveur de contrôle de version Team Foundation pour vous assurer que les données de votre base de données Visual SourceSafe ont été migrées correctement.

    Après avoir suivi ces étapes, vous devrez peut-être résoudre des problèmes. Pour plus d'informations, consultez Vérifier la migration et résoudre les problèmes plus loin dans cette rubrique.

Autorisations requises

Pour exécuter les procédures décrites dans cette rubrique, vous devez disposer des autorisations suivantes :

  • Dans la base de données Visual SourceSafe qui contient les données que vous voulez migrer, vous devez connaître le mot de passe du compte Admin.

  • Sur l'ordinateur de migration (l'ordinateur où Visual Studio est installé), vous devez être membre du groupe Administrateurs.

  • Dans la base de données utilisée par VSSConverter, vous devez disposer de l'autorisation de création de base de données. Pour plus d'informations, consultez Fournir une base de données à utiliser par VSSConverter plus loin dans cette rubrique.

  • Au niveau de la couche Application de Team Foundation, vous devez être membre du groupe de sécurité Team Foundation Administrators. Pour plus d'informations, consultez Autorisations de Team Foundation Server.

Planifier et préparer le processus de migration

Avant de débuter le processus de migration, suivez les étapes de planification et de préparation appropriées pour éviter, vous et votre équipe, d'être confrontés à des problèmes graves.

Prendre en considération les options visant à réduire le délai requis

Le convertisseur fournit des options de migration qui peuvent écourter la migration, soit en réduisant le délai de migration, soit en permettant à vos équipes de travailler sur le contrôle de version pendant la migration. Déterminez l'option de migration la mieux adaptée à votre équipe :

  • Migrez les projets sélectionnés : au lieu de migrer l'ensemble de votre base de données Visual SourceSafe en une seule fois, vous pouvez migrer des projets sélectionnés en plusieurs fois. Pour plus d'informations, consultez Section <ProjectMap> plus loin dans cette rubrique.

  • Tronquez certaines de vos données d'historique : vous pouvez utiliser la fonctionnalité d'archivage de Visual SourceSafe pour effectuer une migration partielle de l'historique. Utilisez cette option, si vous n'êtes pas intéressé par la migration des données d'historique trop anciennes. En utilisant cette fonctionnalité, vous supprimez l'historique des versions de fichiers et de dossiers antérieur à une date spécifique. Pour plus d'informations, consultez Tronquer l'historique des éléments plus loin dans cette rubrique.

Planifier la migration avec votre équipe

Essayez de planifier la migration pour qu'elle s'effectue lorsque les utilisateurs n'ont pas besoin d'accéder à la base de données Visual SourceSafe à migrer. Vous pouvez prendre le temps nécessaire pour préparer et migrer vos données si vous en avez beaucoup, si vous disposez d'une équipe de grande taille, ou si vous travaillez depuis longtemps sur les projets.

Important

Informez les membres de votre équipe lorsque le processus de migration aura lieu, et invitez-les à archiver tous les fichiers avant le début du processus.

Copier et préparer votre base de données Visual SourceSafe

Copiez et préparez votre base de données Visual SourceSafe en procédant comme suit :

  1. Archivez les fichiers.   Dans l'idéal, tous les fichiers de votre base de données Visual SourceSafe doivent être archivés. Essayez d'archiver autant de fichiers que possible.

  2. Supprimez l'accès aux projets Visual SourceSafe.   Vérifiez que vous êtes la seule personne qui a accès aux projets Visual SourceSafe à migrer.

  3. Copiez la base de données.   Suivez les instructions fournies dans la page suivante du site Web Microsoft : Comment sauvegarder une base de données Visual SourceSafe (en anglais).

  4. Mettez à niveau la copie de votre base de données.   Si la version de votre base de données Visual SourceSafe est antérieure à Visual SourceSafe 6.0, mettez-la à niveau vers Visual SourceSafe 2005 à l'aide de l'utilitaire Visual SourceSafe. Pour plus d'informations, consultez la rubrique suivante sur le site Web Microsoft : Utilitaire DDUPD (page éventuellement en anglais).

  5. (Facultatif) Tronquez l'historique des éléments.   Pour plus d'informations, consultez Tronquer l'historique des éléments plus loin dans cette rubrique.

  6. Recherchez et corrigez les problèmes d'intégrité des données dans la copie de votre base de données.   Servez-vous de l'utilitaire ANALYZE de Visual SourceSafe pour trouver et corriger les problèmes d'intégrité des données dans la base de données. Pour plus d'informations sur l'utilisation de cet outil, consultez les pages suivantes sur le site Web Microsoft : Utilitaire ANALYZE et Comment détecter et corriger les erreurs liées aux problèmes d'intégrité de base de données dans Visual SourceSafe (en anglais).

Tronquer l'historique des éléments

Si vous ne voulez pas migrer la totalité de l'historique stocké dans Visual SourceSafe, vous pouvez migrer uniquement l'historique au-delà d'une date spécifique en utilisant la fonctionnalité d'archivage de Visual SourceSafe.

Avertissement

L'utilisation de cette méthode entraîne la suppression définitive de l'historique des versions de la base de données Visual SourceSafe. Par conséquent, veillez à exécuter cette procédure sur une copie de la base de données Visual SourceSafe et non sur la base de données en service.

Pour tronquer l'historique de vos éléments dans Visual SourceSafe, utilisez la fonctionnalité d'archivage de Visual SourceSafe. Vous pouvez spécifier l'horodatage avant lequel vous souhaitez tronquer l'historique, à l'aide de l'une des valeurs suivantes :

  • Étiquette

  • Version d'un dossier

  • Date

Pour plus d'informations sur l'archivage dans Visual SourceSafe, consultez Bases de données d'archivage Visual SourceSafe (page éventuellement en anglais).

Notes

La fonctionnalité d'archivage Visual SourceSafe est limitée à 2 gigaoctets (Go) en matière de taille de fichier d'archivage. Si une erreur se produit au cours du processus, essayez d'archiver séparément des projets plus petits.

Préparer l'ordinateur de migration

Préparez l'ordinateur de migration en procédant comme suit :

  1. Vérifiez que l'ordinateur a suffisamment d'espace disque libre pour effectuer le processus de migration. Pour évaluer l'espace disque requis, additionnez les éléments suivants :

    • 5 Go d'espace disque disponible pour VSSConverter afin de permettre la création des fichiers temporaires et la génération des fichiers journaux.

    • Espace disque égal au double de la taille des projets dans la base de données Visual SourceSafe à migrer.

    • Espace disque suffisant pour installer les applications décrites dans les étapes suivantes.

  2. Installez Visual Studio sur l'ordinateur de migration. 

    Important

    VSSConverter requiert une base de données (SQL Server Express ou SQL Server) pour fonctionner. Par défaut, lorsque vous installez Visual Studio, SQL Server Express est installé, et l'autorisation requise pour le fonctionnement de VSSConverter vous est accordée. Pour plus d'informations, consultez Fournir une base de données à utiliser par VSSConverter plus loin dans cette rubrique.

  3. Installez Visual SourceSafe 2005 sur l'ordinateur de migration.

  4. Installez la mise à jour associée à l'article 950185 dans la Base de connaissances Microsoft. Vous pouvez obtenir ce logiciel à partir de la page suivante du site Web Microsoft : KB950185 - Correctif QFE VSS requis pour VSSConverter d'Orcas SP1.

  5. Vérifiez que vous avez suivi les étapes décrites dans Copier et préparer votre base de données Visual SourceSafe.

  6. Copiez la base de données Visual SourceSafe dans un dossier sur l'ordinateur de migration.

    Avertissement

    Si vous avez recours au partage de fichiers pour permettre à l'ordinateur de migration d'accéder aux données de la base de données Visual SourceSafe au lieu de copier cette dernière, vous devez fournir un accès en lecture et en modification au compte utilisé pour ouvrir une session sur l'ordinateur de migration. Cette approche n'est pas recommandée, car elle peut prolonger le processus de migration.

    Important

    Quelle que soit la façon dont vous configurez votre ordinateur de migration pour accéder à votre base de données Visual SourceSafe, veillez à exécuter le processus de migration sur une copie de la base de données, et non sur la base de données en service. Cette approche contribue à protéger vos données.

Fournir une base de données à utiliser par VSSConverter

VSSConverter requiert une base de données (SQL Server Express ou SQL Server) pour fonctionner. Par défaut, lorsque vous installez Visual Studio, SQL Server Express est installé. Si vous décidez de désactiver cette option lors de l'installation de Visual Studio, vous devez soit installer manuellement SQL Server Express ultérieurement, soit utiliser SQL Server en tant que base de données.

Quelle que soit la base de données utilisée, vous devez disposer de l'autorisation de création de base de données sur cette dernière. Pour SQL Server Express, cette autorisation vous est accordée automatiquement, si vous installez le produit avec Visual Studio.

Si vous voulez utiliser SQL Server à la place de SQL Server Express, vous devez modifier le fichier de paramètres. Pour plus d'informations, consultez Élément <SQL> plus loin dans cette rubrique.

Préparer votre instance de Team Foundation Server

Préparez l'ordinateur de migration en procédant comme suit :

  1. Vérifiez que la couche Données de Team Foundation dispose de suffisamment d'espace de stockage. Vous aurez probablement besoin d'environ deux fois la taille des données des projets dans la base de données Visual SourceSafe à migrer.

    Cette spécification peut être plus importante ou moins importante, selon les facteurs suivants :

    • taille de la base de données Visual SourceSafe à migrer ;

    • nombre d'actions à migrer.

  2. La fonctionnalité de migration requiert l'existence préalable des collections de projets d'équipe et des projets d'équipe sur votre serveur de contrôle de version Team Foundation pour permettre le démarrage du processus de migration. Si vous n'avez pas encore la collection de projets d'équipe ou le projet d'équipe vers lequel vous voulez migrer vos données Visual SourceSafe, effectuez l'une des étapes suivantes ou les deux :

    • créez une collection de projets d'équipe dans laquelle vous voulez migrer les données de votre base de données Visual SourceSafe. Pour plus d'informations, consultez Créer une collection de projets d'équipe.

    • créez un ou plusieurs projets d'équipe dans lesquels vous voulez migrer les données de votre base de données Visual SourceSafe. Pour plus d'informations, consultez Créer un projet d'équipe.

Analyser vos données

Avant d'effectuer une migration de vos données de Visual SourceSafe vers le contrôle de version Team Foundation, vous devez utiliser au préalable la fonctionnalité d'analyse du convertisseur Visual SourceSafe pour déterminer si les éventuels problèmes relatifs à vos données peuvent affecter le résultat de la migration. Cette fonctionnalité génère également un fichier de mappage utilisateur qui permet à la fonctionnalité de migration de migrer vos données.

Créer un fichier de paramètres d'analyse

Pour utiliser la fonctionnalité d'analyse, vous devez créer un fichier de paramètres. Dans ce fichier, vous devez spécifier le chemin d'accès de la base de données Visual SourceSafe et des dossiers à migrer.

Le code XML suivant est un exemple de fichier de paramètres d'analyse.

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
<ConverterSpecificSetting>
     <Source name="VSS">
          <VSSDatabase name="c:\ourvss"></VSSDatabase>
          <UserMap name="c:\ourvss\migrate\Usermap.xml"></UserMap>
     </Source>
     <ProjectMap>
          <Project Source="$/Core"></Project>
          <Project Source="$/ProjectA"></Project>
          <Project Source="$/ProjectB"></Project>
     </ProjectMap>
</ConverterSpecificSetting>
<Settings>
     <Output file="c:\ourvss\migrate\logs\ContosoVSSAnalyze.xml"></Output>
</Settings>
</SourceControlConverter>

Vous pouvez copier l'exemple précédent, le coller dans votre propre fichier de paramètres, puis le modifier. Les informations suivantes peuvent vous aider à adapter l'exemple en fonction de vos besoins.

Attribut <?xml encoding>

L'attribut <?xml encoding> doit correspondre à l'encodage utilisé dans votre fichier de paramètres. Par exemple, si le fichier est enregistré au format Unicode, la balise <?xml encoding> se présente comme suit :

<?xml version="1.0" encoding="unicode">

Attribut <VSSDatabase name>

Dans l'attribut <VSSDatabase name>, spécifiez le chemin d'accès du dossier qui contient le fichier srcsafe.ini pour la copie de la base de données Visual SourceSafe à migrer. Le code suivant est un exemple.

<Source name="VSS">
   ...
   <VSSDatabase name="c:\ourvss"></VSSDatabase>
   ...
</Source>

Le chemin d'accès ne doit pas contenir la chaîne srcsafe.ini. Par exemple, l'attribut <VSSDatabase name> suivant est incorrect et entraîne l'échec de la commande VSSConverter :

<Source name="VSS">
   ...
   <VSSDatabase name="c:\ourvss\srcsafe.ini"></VSSDatabase>
   ...
</Source>

Attribut <UserMap name>

La fonctionnalité d'analyse rassemble et compile les données relatives à vos utilisateurs Visual SourceSafe, puis les stocke dans un fichier XML. Éventuellement, vous pouvez spécifier le chemin d'accès et le nom du fichier où vous souhaitez que ces données soient stockées dans l'attribut <UserMap name>. Si vous ne spécifiez pas cet attribut, la fonctionnalité d'analyse crée un fichier nommé UserMap.xml et le place dans le répertoire actif.

Section <ProjectMap>

Dans la section <ProjectMap>, spécifiez le chemin d'accès de chaque projet Visual SourceSafe que vous voulez migrer dans l'attribut Source d'un élément <Project>.

Pour migrer toutes les données de votre base de données Visual SourceSafe, faites correspondre la section <ProjectMap> à l'exemple suivant :

<ProjectMap>
   <Project From="$/"></Project>
</ProjectMap>

Au lieu de migrer l'ensemble de votre base de données Visual SourceSafe en une seule fois, vous pouvez migrer des projets sélectionnés en plusieurs fois. Cette option vous permet d'éviter de bloquer les équipes pendant la migration, si vous avez de grandes quantités de données à migrer.

Les chemins d'accès des attributs Source doivent être distincts. Par exemple, la section <ProjectMap> suivante n'est pas valide :

<ProjectMap>
   <Project Source="$/ProjectA"></Project>
   <Project Source="$/ProjectA/Controller"></Project>
</ProjectMap>

Attribut <Output file>

Dans la section <Settings>, dans l'attribut <Output file>, vous pouvez spécifier le chemin d'accès et le nom du fichier où vous voulez que le rapport d'analyse soit écrit. Si vous ne spécifiez pas cet attribut, le convertisseur écrit le rapport dans un fichier nommé VSSAnalysisReport.xml et le place dans le répertoire actif.

Élément <SQL>

Pour obliger le convertisseur à utiliser SQL Server à la place de SQL Server Express, vous pouvez ajouter un élément <SQL> à la section <Source> de votre fichier de paramètres de migration. Cet élément utilise la syntaxe suivante : <SQL Server="SQL_Server_name"></SQL>.

Par exemple, l'élément <SQL> suivant indique que le serveur est "ContosoSQLServer" :

<Source name="VSS">
   ...
   <SQL Server="ContosoSQLServer"></SQL>
   ...
</Source>

Exécuter la commande Analyze

Pour analyser un projet à l'aide du convertisseur

  1. Cliquez sur Démarrer, pointez sur Tous les programmes, sur Microsoft Visual Studio 2010, sur Visual Studio Tools, cliquez avec le bouton droit sur Invite de commandes de Visual Studio 10.0, puis cliquez sur Exécuter en tant qu'administrateur.

    Si la boîte de dialogue Contrôle de compte d'utilisateur s'affiche, cliquez sur Continuer.

  2. Tapez la ligne de commande suivante :

    VSSConverter Analyze settings.xml

    Remplacez settings.xml par le chemin d'accès et le nom du fichier de paramètres d'analyse que vous avez créé.

  3. Lorsque vous y êtes invité, fournissez le mot de passe d'administrateur de Visual SourceSafe.

    VSSConverter affiche l'état de progression au fur et à mesure de l'exécution de la fonctionnalité d'analyse. Lorsque le processus est terminé, la fonctionnalité d'analyse génère un rapport et un fichier de mappage utilisateur.

Passer en revue et résoudre les problèmes détectés par la fonctionnalité d'analyse

Le rapport d'analyse fournit des informations sur les problèmes qui affectent votre base de données Visual SourceSafe et qui peuvent entraîner des problèmes supplémentaires au cours du processus de migration. Essayez de résoudre le plus grand nombre possible de problèmes afin de réduire les risques d'échecs du processus de migration, comme décrit dans la section suivante.

Certains fichiers sont extraits

Le rapport répertorie les fichiers qui sont actuellement extraits. Le processus de migration ne conserve pas les informations d'extraction. Dans l'idéal, tous les fichiers de votre base de données Visual SourceSafe doivent être archivés. Essayez d'archiver autant de fichiers que possible.

Certains éléments présentent des problèmes d'intégrité des données

Le rapport répertorie les éléments dont l'intégrité des données a été compromise. Ces éléments ne seront pas migrés. L'utilitaire ANALYZE de Visual SourceSafe peut éventuellement résoudre ce genre de problème. Pour plus d'informations, consultez les pages suivantes sur le site Web Microsoft : Utilitaire ANALYZE et Comment détecter et corriger les erreurs liées aux problèmes d'intégrité de base de données dans Visual SourceSafe (en anglais).

Certains dossiers des projets mappés contiennent un historique qui n'est pas inclus dans la section <ProjectMap>

Si un dossier est déplacé d'un projet à un autre dans une base de données Visual SourceSafe, l'historique de ce dossier est contenu à la fois dans le projet d'origine et le projet actif. Pour migrer ce type de dossier avec l'ensemble de son historique, vous devez migrer à la fois le projet d'origine et le projet actif.

Par exemple, vous migrez le projet Visual SourceSafe Project2. Ce projet contient le dossier $/Project2/FeatureA, qui a été déplacé à partir de Project1 à un moment donné.

Si votre section <ProjectMap> contient…

Par exemple…

Alors…

Les deux projets.

 
<ProjectMap>
   <Project Source="$/Project1"></Project>
   <Project Source="$/Project2"></Project>
</ProjectMap>

Le dossier est migré avec son historique complet.

Le projet qui contenait le dossier à l'origine, mais pas le projet qui le contient actuellement.

 
<ProjectMap>
   <Project Source="$/Project1"></Project>
</ProjectMap>

Le dossier n'est pas migré.

Le projet qui contient le dossier actuellement, mais pas le projet qui le contenait à l'origine.

 
<ProjectMap>
   <Project Source="$/Project2"></Project>
</ProjectMap>

Le dossier est migré avec son historique, qui débute au moment où il a été déplacé vers le projet actif. L'historique antérieur au déplacement du dossier vers le projet actif n'est pas migré.

Pour plus d'informations sur la section <ProjectMap> du fichier de paramètres, consultez la section <ProjectMap> décrite précédemment dans cette rubrique.

Certains noms d'étiquettes ne sont pas pris en charge par le contrôle de version Team Foundation

Le rapport répertorie les noms d'étiquettes qui vont changer lorsqu'ils seront migrés, car ils contiennent des caractères que le contrôle de version Team Foundation ne prend pas en charge.

Migrer vos données

Après avoir exécuté la fonctionnalité d'analyse, vous êtes quasiment prêt à migrer vos données. Avant d'exécuter la commande Migrate, vous devez créer un fichier de paramètres de migration. Éventuellement, vous pouvez spécifier la façon dont les noms d'utilisateurs sont migrés.

Spécifier la façon dont les noms d'utilisateurs sont migrés

Vous pouvez contrôler le mode de migration des informations utilisateur de Visual SourceSafe vers le contrôle de version Team Foundation. Plus précisément, vous pouvez spécifier le nom d'utilisateur que la fonctionnalité de migration doit associer à chaque ensemble de modifications dans l'historique de chaque élément du contrôle de version Team Foundation. Pour ce faire, modifiez le fichier de mappage utilisateur créé lorsque vous avez exécuté la fonctionnalité d'analyse, comme expliqué précédemment dans cette rubrique.

Le fichier de mappage utilisateur est facultatif. Si vous omettez l'élément <UserMap> dans votre fichier de paramètres, chaque ensemble de modifications est construit comme suit :

  • Le champ de l'utilisateur a la valeur du nom du compte sous lequel VSSConverter s'exécute.

  • Le nom de l'utilisateur qui a exécuté l'action dans votre base de données Visual SourceSafe est stocké dans le champ des commentaires.

Exemple de fichier de mappage utilisateur

Lorsque vous exécutez la fonctionnalité d'analyse, elle compile les données relatives à vos utilisateurs Visual SourceSafe et les stocke dans un fichier XML. Ce fichier répertorie chaque utilisateur Visual SourceSafe ayant exécuté une opération de contrôle de version dans les projets Visual SourceSafe que vous migrez.

L'exemple suivant illustre un fichier de mappage utilisateur créé par la fonctionnalité d'analyse du convertisseur Visual SourceSafe.

<?xml version="1.0" encoding="utf-8"?>
<UserMappings>
   <UserMap From="Admin" To=""></UserMap>
   <UserMap From="Guest" To=""></UserMap> 
   <UserMap From="Kim" To=""></UserMap>
   <UserMap From="Satomi" To=""></UserMap>
   <UserMap From="Mark" To=""></UserMap>
</UserMappings>

Vous pouvez spécifier l'attribut To pour une partie, l'ensemble ou aucun des éléments UserMap du fichier de mappage utilisateur. Ainsi, vous pouvez modifier l'exemple précédent comme suit :

<?xml version="1.0" encoding="utf-8"?>
<UserMappings>
   <UserMap From="Admin" To="NORTHAMERICA\KenM"></UserMap>
   <UserMap From="Guest" To="Test1"></UserMap> 
   <UserMap From="Kim" To="EUROPE\KimT"></UserMap>
   <UserMap From="Satomi" To="ASIA\SatomiH"></UserMap>
   <UserMap From="Mark" To=""></UserMap>
</UserMappings>

Notez que dans l'exemple précédent, Guest est mappé à Test1, et qu'aucun domaine n'est spécifié. Dans ce cas, VSSConverter suppose que le compte appartient au domaine par défaut.

Si vous ne spécifiez pas d'attribut <UserMap To>, chaque ensemble de modifications est construit comme suit :

  • Le champ de l'utilisateur a la valeur du nom du compte sous lequel VSSConverter s'exécute.

  • Le nom de l'utilisateur qui a exécuté l'action dans votre base de données Visual SourceSafe est stocké dans le champ des commentaires.

  • Si vous spécifiez un attribut <UserMap To> et si la valeur est celle d'un utilisateur valide sur un serveur qui exécute Team Foundation, le champ de l'utilisateur a la valeur du nom de ce compte. Si la valeur n'est pas celle d'un utilisateur valide sur un serveur qui exécute Team Foundation, VSSConverter affiche une erreur et met fin au processus de migration.

Créer un fichier de paramètres de migration

Vous utilisez le fichier de paramètres de migration pour spécifier les données Visual SourceSafe à migrer, ainsi que pour contrôler plusieurs aspects du mode de migration. La façon la plus simple de créer ce fichier est de copier le fichier que vous avez créé dans la section Créer un fichier de paramètres d'analyse précédemment dans cette rubrique. Vous ajoutez ensuite des données au fichier afin de le rendre utilisable par la fonctionnalité de migration.

L'exemple suivant illustre un fichier de paramètres de migration.

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
<ConverterSpecificSetting>
     <Source name="VSS">
          <VSSDatabase name="c:\ourvss"></VSSDatabase>
          <UserMap name="c:\ourvss\migrate\Usermap.xml"></UserMap>
     </Source>
     <ProjectMap>
          <Project Source="$/Core" Destination="$/CoreTeamProject"></Project>
          <Project Source="$/ProjectA" Destination="$/ClientTeamProject/ProjectA"></Project>
          <Project Source="$/ProjectB" Destination="$/ClientTeamProject/ProjectB"></Project>
     </ProjectMap>
</ConverterSpecificSetting>
<Settings>
     <TeamFoundationServer name="My_Server" port="8080" protocol="http" collection="tfs/DefaultCollection"></TeamFoundationServer>
     <Output file="c:\ourvss\migrate\logs\ContosoVSSMigrate.xml"></Output>
</Settings>
</SourceControlConverter>

Les informations suivantes peuvent vous aider à modifier le fichier de paramètres afin de spécifier la façon dont la fonctionnalité de migration doit migrer vos données.

Attribut <Project Destination>

Pour chaque élément <Project> de la section <ProjectMap> de votre fichier de paramètres, fournissez un attribut Destination afin de spécifier le chemin d'accès de l'emplacement sur votre serveur de contrôle de version Team Foundation où vous voulez migrer le contenu du projet de votre base de données Visual SourceSafe (spécifié dans l'attribut Source).

Par exemple, vous voulez migrer le contenu de ProjectA, de votre base de données Visual SourceSafe, vers ProjectA situé à la racine d'un projet d'équipe appelé Client.

<ProjectMap>
   <Project Source="$/ProjectA" Destination="$/ClientTeamProject/ProjectA"></Project>
</ProjectMap>

Pour que la valeur de l'attribut Destination soit valide, les conditions suivantes doivent être remplies :

  • Le projet d'équipe dans l'attribut Destination (dans l'exemple précédent, le projet d'équipe est ClientTeamProject) doit déjà se trouver dans la collection de projets d'équipe avant le démarrage du processus de migration.

  • Si le dossier dans l'attribut Destination (dans l'exemple précédent, le dossier est ProjectA) se trouve déjà dans le projet d'équipe, le dossier doit être vide.

  • Le chemin d'accès dans l'attribut Destination d'un élément <Project> doit être distinct du chemin d'accès de l'attribut Destination de tous les autres éléments <Project>. Par exemple, la section <ProjectMap> suivante n'est pas valide :

    <ProjectMap>
   <Project Source="$/ProjectA" Destination="$/ClientTeamProjectA/"></Project>
   <Project Source="$/ProjectB" Destination="$/ClientTeamProjectA/ProjectB"></Project>
</ProjectMap>

Balise <TeamFoundationServer>

Dans la section <Settings>, ajoutez une balise <TeamFoundationServer>, puis spécifiez le nom, le port, le protocole et le chemin d'accès de la collection de projets d'équipe sur le serveur qui exécute Team Foundation Server, en utilisant le format suivant :

<TeamFoundationServer name="ServerName" port="PortNumber" protocol="http" collection="path/collection name></TeamFoundationServer>

Balise <Label migrate="false" />

Si votre base de données Visual SourceSafe contient de nombreuses étiquettes appliquées à de nombreux fichiers, le processus de migration peut se prolonger. Si votre équipe n'a pas besoin de ces données, vous pouvez configurer VSSConverter afin d'ignorer les étiquettes, en ajoutant la balise <Label migrate="false" /> à la section <Settings>.

Attribut <Output file>

Dans la section <Settings>, dans l'attribut <Output file>, vous pouvez spécifier le chemin d'accès et le fichier où vous voulez que le rapport de migration soit écrit. Si vous n'incluez pas l'attribut, le convertisseur écrit le rapport dans un fichier nommé VSSMigrationReport.xml et le place dans le répertoire actif.

Exécuter la commande Migrate

Pour exécuter la commande Migrate

  1. Cliquez sur Démarrer, pointez sur Tous les programmes, sur Microsoft Visual Studio 2010, sur Visual Studio Tools, cliquez avec le bouton droit sur Invite de commandes de Visual Studio 10.0, puis cliquez sur Exécuter en tant qu'administrateur.

    Si la boîte de dialogue Contrôle de compte d'utilisateur s'affiche, cliquez sur Continuer.

  2. À l'invite de commandes, tapez la ligne de commande suivante :

    VSSConverter Migrate settings.xml

    Remplacez settings.xml par le chemin d'accès et le nom du fichier de paramètres de migration que vous avez créé.

    La fonctionnalité de migration affiche chaque projet migré à partir de votre base de données Visual SourceSafe et chaque dossier de destination des données migrées sur votre serveur de contrôle de version Team Foundation.

  3. Lorsque vous y êtes invité, cliquez sur Y pour confirmer la suppression.

  4. Lorsque vous y êtes invité, tapez le mot de passe de l'utilisateur qui administre votre base de données Visual SourceSafe.

Au cours du processus, la fonctionnalité de migration affiche son état actuel dans la fenêtre d'invite de commandes.

Reprendre le processus à l'aide de la migration incrémentielle

Si le processus de migration est interrompu pour une raison quelconque, vous pouvez le reprendre sous forme de migration incrémentielle à partir du point où le processus s'est terminé. Une migration incrémentielle peut être utile si le processus de migration a échoué en raison d'une erreur ou de problèmes réseau. Durant la migration incrémentielle, le convertisseur migre uniquement les données qui n'ont pas été migrées au cours des sessions précédentes.

Pour démarrer une migration incrémentielle, suivez les étapes décrites dans Exécuter la commande Migrate. Lorsque la fonctionnalité de migration vous demande si vous voulez exécuter une migration incrémentielle, appuyez sur Y.

Limitations d'une migration incrémentielle

Une migration incrémentielle est vouée à l'échec si vous ne tenez pas compte des restrictions suivantes :

  • Dans votre base de données Visual SourceSafe, vous ne devez pas effectuer d'activités de destruction, de purge, d'archivage ou de restauration.

  • Vous ne devez pas modifier la section <ProjectMap> de votre fichier de paramètres de migration.

  • Sur votre serveur de contrôle de version Team Foundation, vous ne devez modifier aucun des dossiers (ni aucun contenu des dossiers) spécifiés dans la section <ProjectMap> de votre fichier de paramètres de migration.

Vérifier la migration et résoudre les problèmes

Une fois terminée l'exécution de la fonctionnalité de migration, procédez comme suit :

  • Passez en revue le rapport généré par la fonctionnalité de migration.

  • Vérifiez les données sur votre serveur de contrôle de version Team Foundation pour vous assurer que les données ont été migrées correctement.

Après avoir suivi ces étapes, vous devrez peut-être résoudre des problèmes.

Comment résoudre le problème de dépassement de la limite de stockage pour SQL Server Express

Par défaut, VSSConverter utilise SQL Server Express pour stocker des métadonnées temporaires. En règle générale, ces métadonnées requièrent un faible pourcentage de la taille totale des données à migrer. Dans l'hypothèse peu probable où la migration échouerait en raison du dépassement de la limite des 4 Go de SQL Server Express, vous pouvez appliquer un paramètre qui oblige le convertisseur à utiliser un déploiement SQL Server à la place. Pour plus d'informations, consultez Élément <SQL> précédemment dans cette rubrique.

Convertir des fichiers au format de nom court (8.3) compatible MS-DOS (TF227014)

Le contrôle de version Team Foundation n'autorise pas les noms de fichiers au format de nom court (8.3) compatible MS-DOS (par exemple abcdef~1.txt). Lorsque vous analysez ou tentez de migrer des fichiers qui portent ce type de nom, une erreur TF227014 s'affiche.

Pour contourner ce problème, vous pouvez appliquer temporairement un paramètre au niveau de votre couche Application pour Team Foundation afin de l'obliger à autoriser les fichiers ayant de tels noms. Pour ce faire, vous devez affecter True à Allow8Dot3Paths dans la base de données de configuration de Team Foundation.

Important

Pour éviter les problèmes liés aux ordinateurs clients qui prennent en charge les noms courts compatibles MS-DOS, il est fortement recommandé d'affecter False à Allow8Dot3Paths à l'issue du processus de migration, comme décrit dans la procédure suivante.

Pour exécuter la procédure suivante, vous devez activer Windows PowerShell sur le serveur de couche Application pour Team Foundation. Pour plus d'informations, consultez la rubrique suivante sur le site Web Microsoft : Génération de scripts avec Windows PowerShell.

Autorisations requises

Pour effectuer cette procédure, vous devez être membre du groupe Administrateurs sur le serveur de couche Application pour Team Foundation. Pour plus d'informations, consultez Autorisations de Team Foundation Server.

Pour migrer une base de données Visual SourceSafe qui contient des fichiers nommés à l'aide du format de nom court compatible MS-DOS

  1. Connectez-vous au serveur de couche Application de Team Foundation.

  2. Créez un script Windows PowerShell appelé Allow8Dot3Paths.

    1. Copiez le texte contenu dans Script PowerShell Allow8Dot3Paths, puis collez-le dans le script.

    2. Modifiez ServerPath de sorte qu'il corresponde au chemin d'accès de l'URL utilisée pour la connexion à Team Foundation Server. Par défaut, le chemin d'accès du serveur est "tfs".

    3. Modifiez CollectionName de sorte qu'il corresponde au nom de la collection de projets d'équipe dans laquelle vous migrez vos données (par exemple DefaultCollection).

      Le résultat final correspond à la ligne suivante dans le script :

      $collectionBaseUrl = "https://localhost:8080/tfs/DefaultCollection/";

  3. Exécutez le script Allow8Dot3Paths.

  4. Recyclez le pool d'applications pour Team Foundation.

    1. Cliquez sur Démarrer, sur Outils d'administration, puis sur Gestion de l'ordinateur.

    2. Dans le volet de navigation, développez Services et applications.

    3. Cliquez sur Gestionnaire des services Internet (IIS), développez l'ordinateur local, puis double-cliquez sur Pools d'applications.

    4. Cliquez avec le bouton droit sur le pool d'applications, puis cliquez sur Recycler.

  5. Exécutez la commande Migrate.

    Pour plus d'informations, consultez Exécuter la commande Migrate.

  6. Modifiez le script Windows PowerShell Allow8Dot3Paths que vous avez créé précédemment, en remplaçant "true" par "false".

  7. Exécutez le script Allow8Dot3Paths modifié.

  8. Recyclez le pool d'applications pour Team Foundation.

    1. Cliquez sur Démarrer, sur Outils d'administration, puis sur Gestion de l'ordinateur.

    2. Dans le volet de navigation, développez Services et applications.

    3. Cliquez sur Gestionnaire des services Internet (IIS), développez l'ordinateur local, puis double-cliquez sur Pools d'applications.

    4. Cliquez avec le bouton droit sur le pool d'applications, puis cliquez sur Recycler.

  9. Ouvrez Team Explorer, puis connectez-vous à la collection de projets d'équipe dans laquelle vous avez migré les données.

  10. Dans l'Explorateur du contrôle de code source, renommez tous les fichiers dont les noms sont au format de nom court (8.3) compatible MS-DOS.

Script PowerShell Allow8Dot3Paths

# Load client OM assembly.
[Reflection.Assembly]::Load("Microsoft.TeamFoundation.Client, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");

$collectionBaseUrl = "https://localhost:8080/ServerPath/CollectionName/";

$tfs = [Microsoft.TeamFoundation.Client.TeamFoundationServerFactory]::GetServer($collectionBaseUrl);
$collectionHive = $tfs.GetService([Microsoft.TeamFoundation.Framework.Client.ITeamFoundationRegistry]);

# Set some version control settings in the collection hive.
$collectionHive.SetValue("/Service/VersionControl/Settings/Allow8Dot3Paths", "True");

# Display all version control settings as a table.
$collectionHive.ReadEntries("/Service/VersionControl/Settings/...") | ft -a

Comment VSSConverter convertit vos données

Team Foundation et Visual SourceSafe présentent des différences fonctionnelles significatives. Par conséquent, VSSConverter doit modifier certains genres de données lors de leur migration.

Ensembles de modifications

La façon dont le contrôle de version Team Foundation regroupe les modifications de plusieurs fichiers en une seule unité lorsqu'un utilisateur archive un ensemble de modifications, est une fonctionnalité clé. Cette unité unique s'appelle un ensemble de modifications.

Visual SourceSafe n'a pas de fonctionnalité équivalente aux ensembles de modifications. Toutefois, durant le processus de conversion, chaque ensemble de modifications est regroupé en un ensemble de modifications tant que les conditions suivantes sont remplies :

  • Les modifications ne sont pas en conflit entre elles. Par exemple, deux actions n'affectent pas le même fichier ou dossier.

  • Les modifications ne se sont produites qu'à quelques minutes d'intervalle, l'une de l'autre.

  • Les modifications ont été archivées par le même utilisateur.

  • Les modifications ont le même commentaire d'archivage.

Pour plus d'informations, consultez Utilisation d'ensembles de modifications.

Partage et épinglage

Dans Visual SourceSafe, vous pouvez partager un fichier dans plusieurs dossiers. Les modifications que vous apportez dans un fichier partagé sont répliquées dans les dossiers où le fichier est partagé. Le contrôle de version Team Foundation n'a pas de fonctionnalité équivalente. Durant la migration, les fichiers partagés de votre projet Visual SourceSafe sont migrés via la création d'une copie indépendante supplémentaire de l'élément sur votre serveur de contrôle de version Team Foundation.

Le contrôle de version Team Foundation n'a pas de fonctionnalité équivalente à la fonctionnalité d'épinglage de Visual SourceSafe. Durant la migration, les éléments épinglés dans le projet Visual SourceSafe sont convertis en éléments étiquetés sur votre serveur de contrôle de version Team Foundation. Pour plus d'informations, consultez la section suivante.

Pour plus d'informations sur les étiquettes dans le contrôle de version Team Foundation, consultez Utiliser des étiquettes pour prendre un instantané de vos fichiers.

Données d'historique

Chaque événement de l'historique d'un élément de votre base de données Visual SourceSafe est transféré sur votre serveur de contrôle de version Team Foundation en tant qu'ensemble de modifications. Une fois le processus de migration effectué, vous pouvez consulter ces données dans la fenêtre Historique. Pour plus d'informations, consultez Utilisation de la fenêtre Historique.

Certaines modifications sont apportées aux données durant la migration.

Mode de migration des données relatives au nom d'utilisateur et à l'horodatage

Chaque fois qu'une entrée de l'historique d'un élément de votre base de données Visual SourceSafe est migrée vers un ensemble de modifications sur votre serveur de contrôle de version Team Foundation, les modifications suivantes se produisent :

  • L'horodatage de l'ensemble de modifications a la valeur de l'horodatage de la migration de l'élément.

  • L'horodatage d'origine est stocké dans le champ des commentaires de l'ensemble de modifications.

  • Le nom d'utilisateur est stocké dans le champ de l'utilisateur ou le champ des commentaires de l'ensemble de modifications, selon le résultat du processus de mappage utilisateur. Pour plus d'informations, consultez Spécifier la façon dont les noms d'utilisateurs sont migrés précédemment dans cette rubrique.

Mode de conversion des types d'événements spécifiques

Les événements tels que la modification, le changement de nom et la suppression sont migrés de manière simple de votre base de données Visual SourceSafe vers les ensembles de modifications sur votre serveur de contrôle de version Team Foundation. Toutefois, VSSConverter migre certains événements de manière parfois inattendue, comme le montre le tableau suivant.

Événement Visual SourceSafe

Mode de migration vers Team Foundation

Ajouter un fichier ou un dossier

Cet ensemble de modifications est le premier événement de l'historique de chaque fichier et dossier migré.

Contrairement à Visual SourceSafe, aucun événement n'est enregistré pour le parent de chaque élément enfant qu'il contient.

Création de branche

Le partage est une condition préalable de la création de branche dans Visual SourceSafe ; toutefois, le contrôle de version Team Foundation ne prend pas en charge le partage. Par conséquent, la migration d'un fichier qui possède des branches entraîne la création d'une copie du fichier dans le dossier de destination. 

Les fichiers partagés de votre base de données Visual SourceSafe sont migrés vers le contrôle de version Team Foundation comme suit : la version du fichier qui existait lorsqu'il était partagé est copiée et placée dans le dossier de destination. Par la suite, chaque ensemble de modifications est répliqué dans les deux copies du fichier jusqu'à ce que l'événement de branche se produise.

Étiqueter un fichier 

Dans Team Foundation, vous appliquez une étiquette à la version d'un fichier ou d'un dossier. Dans Visual SourceSafe, vous pouvez étiqueter un fichier de manière explicite ou implicite. Lorsqu'un fichier est étiqueté de manière explicite dans Visual SourceSafe, une nouvelle version du fichier est créée. Si vous obtenez des fichiers à l'aide de cette étiquette, vous récupérez le contenu du fichier qui correspond à la version du fichier qui existait lorsque l'étiquette a été créée. Pour migrer des étiquettes de manière explicite, le convertisseur prend l'étiquette qui correspond à la version étiquetée dans Visual SourceSafe et l'applique à la version située dans Team Foundation. Toutefois, il ne crée pas d'autre version.

Lorsque vous appliquez une étiquette à un dossier dans Visual SourceSafe, elle est appliquée de manière implicite à tous les fichiers et dossiers de ce dossier ; en outre, le convertisseur ne crée pas d'autres versions. Pour les étiquettes implicites, le convertisseur ne fait rien, car les versions correspondantes dans Team Foundation sont étiquetées automatiquement durant la migration des étiquettes explicites du dossier.

RemarqueRemarque
Si votre base de données Visual SourceSafe contient de nombreuses étiquettes appliquées à de nombreux fichiers, le processus de migration peut se prolonger.Si votre équipe n'a pas besoin de ces données, vous pouvez configurer VSSConverter afin d'ignorer les étiquettes.Pour plus d'informations, consultez <Label migrate="false" /> précédemment dans cette rubrique.

Étiqueter un dossier

Dans Visual SourceSafe, lorsque vous appliquez une étiquette à un dossier, tous les fichiers et dossiers contenus dans ce dossier sont étiquetés de manière implicite ; en outre, aucune autre version n'est créée. Durant la migration de ces dossiers, le convertisseur applique l'étiquette à la version correspondante du dossier dans Team Foundation. Ce comportement entraîne l'application automatique de l'étiquette aux versions actuelles des fichiers et dossiers du dossier étiqueté.

RemarqueRemarque
Si votre base de données Visual SourceSafe contient de nombreuses étiquettes appliquées à de nombreux fichiers, le processus de migration peut se prolonger.Si votre équipe n'a pas besoin de ces données, vous pouvez configurer VSSConverter afin d'ignorer les étiquettes.Pour plus d'informations, consultez <Label migrate="false" />.

Déplacer un dossier

L'événement relatif au déplacement d'un dossier entraîne la création d'une autre version du dossier dans Team Foundation.

VSSConverter ne migre pas l'historique complet des éléments des dossiers déplacés, sauf si les dossiers sources et de destination sont migrés en même temps. Pour plus d'informations, consultez Passer en revue et résoudre les problèmes détectés par la fonctionnalité d'analyse.

RemarqueRemarque
Si l'événement de déplacement d'un dossier est associé à un événement de restauration, les données d'historique risquent de ne pas être migrées correctement.

Restaurer

Aucune donnée d'historique antérieure à un événement de restauration n'est migrée.

PIN et UNPIN

Le contrôle de version Team Foundation ne prend pas en charge l'épinglage. VSSConverter migre un fichier épinglé en créant deux étiquettes.

L'étiquette PINNED_LATEST est appliquée aux versions épinglées des fichiers épinglés et à la version la plus récente des fichiers désépinglés. L'étiquette PINNED est uniquement appliquée aux versions épinglées des fichiers épinglés. Après la migration, l'étiquette PINNED_LATEST récupérera les mêmes fichiers qu'une commande Obtenir la dernière version dans Visual SourceSafe. Toutefois, l'étiquette PINNED_LATEST peut retourner des fichiers différents, si des événements autres qu'un archivage ont eu lieu après l'épinglage d'un fichier, par exemple un changement de nom ou une suppression du fichier.

Partage

Le contrôle de version Team Foundation ne prend pas en charge le partage. Les fichiers partagés de votre base de données Visual SourceSafe sont migrés vers le contrôle de version Team Foundation comme suit : la version du fichier qui existait lorsqu'il était partagé est copiée et placée dans le dossier de destination. Par la suite, chaque ensemble de modifications est répliqué dans les deux copies du fichier.

Restaurer un fichier ou un dossier

Durant la migration d'événements de restauration d'un fichier ou d'un dossier, le convertisseur relit l'événement afin de créer une autre version du fichier et du dossier dans Team Foundation.

VSSConverter crée un ensemble de modifications qui inclut le nom du fichier ou du dossier, l'horodatage de sa restauration, ainsi que le nom d'utilisateur.

Liaisons du contrôle de code source

VSSConverter restaure les liaisons de contrôle de version de chaque solution.