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 déficiences de VSS, il a décidé de migrer de VSS vers SVN Subversion.

Le choix à faire semble être Tortoise SVN avec AnkhSVN (bon choix ?). Une aide à la migration est décrit ici . Le projet contient deux sites web, quelques applications web, plusieurs bibliothèques de contrôle et de fonctions.

Il me semble qu'un "balayer tout ce qui est lié à VSS" et ensuite "importer en SVN" est la voie à suivre. Mais les mondes ne sont pas parfaits. Quels sont les problèmes auxquels nous devons faire attention et quelles mesures pouvons-nous prendre pour que ce processus se déroule sans problème ? Y a-t-il des problèmes typiques de SVN pour .NET dont nous devrions être conscients ?

EDIT : Est-il possible de migrer également l'historique de VSS, ou devons-nous considérer qu'il s'agit d'un nouveau départ seulement ?

Answer 1

Nous avons effectué la même migration il y a quelques années et avons été très satisfaits des résultats. Comme Pino, je recommande Tortoise SVN. AnkhSVN n'a pas semblé bien fonctionner pour nous. Je ne connais pas de moyen pratique de migrer l'historique.

Les principaux problèmes 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 sont les suivants :

1. Apprendre à travailler avec des caisses fusionnées et non exclusives.
2. Apprendre que rien n'est jamais supprimé dans Subversion. Ainsi, ajouter votre installateur avec les prérequis, puis le supprimer ne réduira pas la taille du référentiel. La taille de notre sauvegarde actuelle est de 4GB+ compressée.
3. Les sauvegardes nécessitent un peu de script, contrairement à SourceSafe qui était une simple copie de fichier. svnadmin hotcopy a fonctionné pour nous.
4. Nous avons constaté que les "branches d'utilisateurs", où chaque utilisateur a une branche différente, ne fonctionnaient pas pour nous. Nous avons maintenant un tronc unique pour tous les utilisateurs.
5. Il était possible de valider une modification sans commentaire. Vous pouvez corriger cela avec un hook de pré-commissionnement.
6. Abandon de l'intégration de MS Visual Studio. Ce n'est pas aussi grave que ça en a l'air.

Answer 2

Il existe plusieurs outils qui peuvent migrer l'historique pour vous. Nous avons utilisé VSS2SVN il y a quelques années pour faire cette même démarche.

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 (Gratuit, fournisseur complet de SCC pour VS 2005+ depuis AnkhSVN 2.0) et VisualSVN (Commercial ; Utilise TortoiseSVN avec ses propres extensions et fournit des fonctionnalités similaires à SCC dans VS 2003+).

Je recommanderais également d'installer une installation SVN en ligne de commande normale pour une utilisation par scripts.

Ver AnkhSVN vs VisualSVN pour plus de comparaisons entre VisualSVN et AnkhSVN. Mais notez que tous les clients (TortoiseSVN, AnkhSVN, VisualSVN) sont juste une coquille sur les mêmes bibliothèques, donc vous pouvez passer de l'un à l'autre quand vous le souhaitez.

Answer 3

Le plus grand obstacle, et de loin, sera d'éduquer les développeurs aux différences d'utilisation des systèmes de contrôle de source.

Checkout Edit Checkin to Edit Merge Commit :

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

Liaison du projet à la liaison du système de fichiers :

VSS gère généralement le contrôle des sources au niveau du projet et de la solution. Le projet est lié au contrôle de source et toute modification apportée au projet l'est également au contrôle de source. Dans SVN, il n'y a pas de lien de ce type. Toutes les modifications sont suivies au niveau du système de fichiers, ce qui signifie que lorsque vous ajoutez un nouveau fichier à votre projet, vous également doivent ajouter le fichier au contrôle de la source.

Rien que pour cette raison, je recommande d'investir du temps pour mettre en place un serveur d'intégration continue pour vos projets. Cela permettra de détecter rapidement tous les fichiers manquants dans les commits et d'éviter le scénario gênant où d'autres développeurs font un checkout et obtiennent des erreurs de construction parce qu'un fichier est référencé dans votre projet, mais n'est pas présent dans votre contrôle de source.

Ramification :

Bien que vous puissiez effectuer des branchements dans VSS, j'ai rarement vu quelqu'un l'utiliser car il est assez délicat de mettre en place une branche, de passer à une branche et de fusionner la branche lorsque vous avez terminé. La création de branches n'est pas obligatoire pour utiliser SVN, mais c'est probablement l'une des principales raisons pour lesquelles vous feriez le changement. Les développeurs doivent être à l'aise avec l'idée de créer des branches là où cela semble approprié et de les fusionner dans le tronc.

Si vos développeurs sont déjà à l'aise avec l'utilisation de SVN, vous ne devriez pas avoir de problèmes. Si ce n'est pas le cas, ils auront peut-être besoin d'un peu d'aide pour voir les avantages de SVN par eux-mêmes et, espérons-le, finir par aimer l'utiliser.

Answer 4

Le conseil numéro un : Gardez une sauvegarde :) Deuxièmement : Tortoise SVN - Définitivement la voie à suivre pour une machine Windows, en plus de s'intégrer à Visual Studio (via VisualSVN).