Comment convaincre mon équipe d'abandonner Sourcesafe et de passer à SVN ?

Question

Mon équipe de développement utilise le coffre-fort des sources à un niveau très basique. Nous entrons dans des cycles de développement plus avancés et plus longs et je ne peux m'empêcher de penser que le fait de ne pas utiliser le branchement et la fusion pour gérer les changements va bientôt nous coûter cher.

Quels sont les arguments que vous avez trouvés les plus utiles pour convaincre votre équipe de passer à une meilleure solution comme SVN ?

Quels programmes avez-vous utilisés pour combler l'écart de fonctionnalité afin que l'équipe ne rate pas l'intégration de Sourceafe ?

Ou dois-je simplement accepter la sécurité des sources et tenter d'y intégrer de meilleures pratiques ?

Answer 1

Fiabilité

• SVN est beaucoup plus fiable pour les grandes bases de données.
• SVN est toujours activement supporté
• Atomic commit - dans VSS lorsque vous obtenez la dernière version alors qu'un autre utilisateur effectue un checkin, vous pouvez obtenir un état incohérent, vous obligeant à répéter le "Get latest version" dans le meilleur des cas, mais parfois, si vous êtes malchanceux, vous pouvez vous retrouver avec une base de code qui compile mais ne fonctionne pas. Cela ne peut pas arriver dans SVN grâce aux commits atomiques.

Caractéristiques

• La fusion/branche SVN est bien meilleure.
• SVN a un support intégré pour l'accès à distance
• SVN est plus configurable (intégration d'outils externes de Diff/Fusion).
• SVN est plus extensible (hooks)

Une meilleure productivité

• SVN "Update" est une beaucoup plus rapide que le SS "Obtenir la dernière version"
• La ligne de commande SVN est beaucoup plus simple et plus propre, ce qui est utile pour les outils de construction ou de test automatisés.

Même niveau d'intégration IDE

• VSS avait une bien meilleure intégration avec VS jusqu'à récemment, mais avec AnkhSVN 2.0 ce n'est plus vrai.

Ouvrir

SVN est ouvert et il existe de nombreux outils variés qui utilisent SVN ou qui coopèrent avec lui. Voici quelques exemples :

• intégration avec de nombreux produits de suivi des bogues ou de gestion du cycle de vie des produits
• intégration de la coquille
• l'intégration dans divers produits
• divers outils de gestion et d'analyse
• La source est disponible, vous pouvez l'adapter à vos besoins, résoudre les problèmes (ou engager quelqu'un pour le faire) si nécessaire.

Coût

• Vous ne devez pas payer de frais de licence ou de maintenance.

Answer 2

Tout d'abord, apprenez-leur à utiliser SourceSafe de manière efficace.

S'ils sont suffisamment intelligents, ils commenceront à apprécier les avantages de l'utilisation d'un système de contrôle de version et, dans ce cas, ils atteindront bientôt les limites de SourceSafe. C'est là qu'ils seront le plus à même d'écouter vos arguments pour passer à un meilleur VCS, que ce soit un CVCS ou un DVCS, en fonction de ce que l'équipe est prête à réaliser.

Si vous essayez de les forcer à utiliser un autre VCS lorsqu'ils utilisent SourceSafe de manière incorrecte, par exemple en sauvegardant un fichier zip du code source (ne riez pas, c'est ainsi qu'ils agissaient dans mon entreprise il y a deux ans), ils seront totalement réticents à toute argumentation, aussi bonne soit-elle.

Answer 3

Trouvez une excuse pour commencer à utiliser des caractères non ASCII dans votre code C# (Le chinois et le japonais sont excellents pour cela).

SourceSafe n'aime pas l'Unicode (même si Visual Studio l'aime), donc si vous choisissez le bon texte Unicode et que vous enregistrez un fichier puis le retirez, votre fichier entier apparaîtra comme un charabia corrompu. La beauté de la chose, c'est que, comme SS utilise un système de versionnement "diff", cela corrompt en fait le fichier jusqu'à la version d'archivage originale, et ne peut pas être corrigé automatiquement.

Lorsque cela se produit une seule fois (comme ce fut le cas pour moi lorsque je travaillais sur une application qui devait prendre en charge le japonais), vous trouverez probablement que c'est un argument décisif en faveur de l'abandon de SourceSafe.

Answer 4

Il y avait deux caractéristiques que nous utilisions pour convaincre la direction et l'équipe de préférer SVN à VSS.

1) La possibilité de créer des branches. En utilisant VSS, lorsqu'une version était programmée pour sortir, l'ensemble du référentiel était verrouillé jusqu'à ce que la version sorte effectivement. Cela incluait le cycle de test et de correction. Ainsi, les développeurs étaient incapables de commettre tout ce qui est autres que les correctifs pour la version au référentiel VSS. Cela a donné lieu à de longues sessions d'intégration immédiatement après chaque version. Avec l'utilisation des branches de version dans SVN, il n'est plus nécessaire de verrouiller l'ensemble du référentiel.

2) La possibilité d'annuler un changement entier en une seule fois. Parce que SVN enregistre tous les fichiers modifiés dans un seul commit atomique, il est trivial de revenir sur un changement problématique. Dans VSS, un développeur devait parcourir l'ensemble du référentiel, trouver tous les fichiers modifiés à peu près au même moment et annuler chaque changement sur chaque fichier individuellement. Avec SVN, c'est aussi trivial que de trouver le commit pertinent et d'appuyer sur le bouton " Revenir sur les changements de ce commit " dans TortoiseSVN.

A titre d'information, nous utilisons TortoiseSVN et tout le monde aime les icônes de superposition de fichiers pour voir ce qui a été modifié ou non.

Answer 5

Quoi que vous fassiez, avancez lentement ! Ne commencez pas à leur parler de branchement dès le premier jour, cela ne fera que les décourager. Je suis en train de stéréotyper les utilisateurs de VSS avec ce commentaire, mais c'est ce que je vois là-bas.

Pour les développeurs : le vendre comme un remplacement de VSS qui fonctionne mieux et plus vite. Utilisez VisualSVN dès le premier jour pour que la courbe d'apprentissage soit très courte. Vendez-leur que c'est la même chose sauf que c'est plus rapide, plus stable, et que 2 personnes peuvent éditer le même fichier et qu'ils n'auront pas de problèmes avec un gars qui est en arrêt maladie avec des verrous sur un tas de fichiers.

Pour les administrateurs : les convaincre qu'il est plus stable et plus facile à administrer que VSS. Montrez-leur Serveur VisualSVN .

Bonne chance !