Quels sont les obstacles et les dangers lors de la migration de Visual SourceSafe vers SVN?

Question

Un client utilise toujours Visual SourceSafe, mais après avoir montré les nombreux dangers et les lacunes de VSS, ils ont décidé de migrer de VSS vers SVN Subversion. Le choix-à-être semble Tortoise SVN avec AnkhSVN (bon choix?). Une aide à la migration is described here. Le projet contient deux sites Web, quelques applications Web, plusieurs bibliothèques de contrôle et de fonctions.

Il me semble qu'un "sweep all VSS related", puis "importer dans SVN" est la voie à suivre. Mais les mondes ne sont pas parfaits. Quels sont les problèmes que nous devrions surveiller et quelles mesures pouvons-nous prendre pour que ce processus se déroule bien? Existe-t-il des problèmes SVN typiques pour .NET dont nous devrions être conscients?

EDIT: est-il possible en quelque sorte de migrer l'historique VSS aussi, ou devrions-nous considérer cela comme un nouveau démarrage seulement?

Answer 1

Nous avons fait la même migration il y a quelques années et nous sommes très satisfaits des résultats. Comme Pino, je recommande Tortoise SVN. AnkhSVN ne semblait pas bien fonctionner pour nous. Je ne connais pas de façon pratique de migrer l'histoire.

Les problèmes majeurs que nous avons rencontrés étaient dus à la nature même de Subversion et non à la migration. Les problèmes que nous avons rencontrés étaient les suivants:

1. Apprendre à travailler avec la fusion et non pas les contrôles exclusifs.
2. Apprendre que rien n'est jamais supprimé dans Subversion. L'ajout de votre programme d'installation avec les prérequis, puis sa suppression ne réduira pas la taille du référentiel. Notre taille de sauvegarde actuelle est de 4 Go + compressée.
3. Les sauvegardes nécessitent un peu de script, contrairement à SourceSafe qui était une simple copie de fichier. svnadmin hotcopy travaillé pour nous.
4. Nous avons constaté que les 'branches d'utilisateur' où chaque utilisateur a une branche différente ne fonctionnaient pas pour nous. Nous avons maintenant un seul tronc pour tous les utilisateurs.
5. Il était possible de valider une modification sans commentaire. Vous pouvez corriger cela avec un hook de pré-commit.
6. Renonciation à l'intégration de MS Visual Studio. Pas aussi mauvais que cela puisse paraître.

Answer 2

Numéro un conseil: Gardez une copie de sauvegarde :) Numéro deux: tortoisesvn - Defo la voie à suivre pour une machine Windows, plus intègre avec Visual Studio (Via VisualSVN)

Answer 3

De loin le plus grand obstacle éduquera les développeurs aux différences dans l'utilisation des systèmes de contrôle de la source.

Commander Modifier Entrée pour modifier Merge Commit:

aux développeurs de nouvelles SVN doivent être à l'aise avec l'idée de deux développeurs d'apporter des modifications à un fichier en même temps, et ils fusionneront ces changements plus tard . Les utilisateurs de VSS ne savent généralement pas que ce style de contrôle de source est même possible et ne se sentent certainement pas à l'aise avec la transition.

projet de liaison au système de fichiers Reliure:

VSS gère généralement le contrôle des sources au niveau du projet et la solution. Le projet est lié au contrôle de la source et tous les changements qui arrivent au projet arrivent également au contrôle de la source. Dans SVN, il n'y a pas une telle liaison. Toutes les modifications sont suivies sur le système de fichiers, ce qui signifie que lorsque vous ajoutez un nouveau fichier à votre projet, vous devez également ajouter le fichier au contrôle source.

Pour cette seule raison, je vous recommande de consacrer du temps à la mise en place d'un serveur d'intégration continue pour vos projets. Cela permet de détecter rapidement les fichiers qui ne sont pas validés et empêche le scénario bizarre d'autres développeurs d'effectuer une extraction et d'obtenir des erreurs de construction car un fichier est référencé dans votre projet mais n'est pas présent dans votre contrôle source.

Branching:

Bien que vous puissiez effectuer des ramifications dans VSS, je l'ai rarement vu quelqu'un l'utiliser car il est assez difficile de mettre en place une branche, passer à une branche, puis fusionner la branche lorsque vous » re fini avec ça. Le branchement n'est pas requis pour utiliser SVN, mais c'est probablement l'une des principales raisons pour lesquelles vous devriez changer de fournisseur. Les développeurs doivent se familiariser avec l'idée de créer des succursales là où cela semble approprié et de les fusionner dans le réseau.

Si vos développeurs sont déjà à l'aise avec l'utilisation de SVN, vous ne devriez avoir aucun problème. Sinon, ils peuvent avoir besoin d'un peu de conseils pour leur faire voir les avantages de SVN pour eux-mêmes, et, espérons-le, finissent par en profiter.

Answer 4

Plusieurs outils peuvent migrer l'historique pour vous. Nous avons utilisé VSS2SVN il y a quelques années pour faire ce même pas.

Vous pouvez utiliser plusieurs clients subversion côte à côte. Presque tous les utilisateurs Windows de Subversion que je connais utilisent TortoiseSVN et pour l'intégration dans Visual Studio, vous pouvez utiliser AnkhSVN (Free, fournisseur SCC complet pour VS 2005+ depuis AnkhSVN 2.0) et VisualSVN (Commercial; Utilise TortoiseSVN avec ses propres extensions et fournit SCC-like caractéristiques dans VS 2003+).

Je vous recommande également d'installer une installation SVN en ligne de commande normale à utiliser par les scripts. Voir AnkhSVN vs VisualSVN pour plus de comparaisons entre VisualSVN et AnkhSVN. Mais notez que tous les clients (TortoiseSVN, AnkhSVN, VisualSVN) sont juste un shell sur les mêmes bibliothèques, vous pouvez donc basculer entre eux quand vous le souhaitez.