Après avoir passé toute la matinée à essayer d'enregistrer quelque chose, je me rends compte maintenant que j'ai perdu quelques jours de travail.

C'est déjà arrivé - et c'est apparemment fréquent avec SourceSafe. SourceSafe peut-il être utilisé avec succès, sans problème, et si oui, comment?

Ma vue est simple, migrez vers autre chose dès que possible. Cela ne prendra pas longtemps (1-2 semaines WAG) et peu importe la durée de la migration, il est facile de justifier cela à la direction. Un peu de temps pour migrer équivaut à un contrôle de source solide et très peu de chances de perdre le code source. Effectuez une recherche rapide sur Google pour les "histoires d'horreur sûres à la source" ou similaire si votre patron est sceptique.

Pire. SCM. Déjà.

Tout ce qui ne va pas dans SCM est incarné dans VSS. Même StarTeam est meilleur que Source Safe. Source Safe est Internet Explorer 1 du monde du contrôle de version: entièrement remplacé par toute autre implémentation.

Comment l'ai-je utilisé?

Mon flux de travail typique pour faire avancer les choses était

1. Découvrez le projet
2. Verrouillez tous les fichiers (pour éviter de fusionner avec le cos de quelqu'un qui a ouvert les portes impies de l'enfer)
3. A fait mon travail
4. Chaque jour vérifié mes changements dans
5. J'ai tout vérifié à nouveau et corrigé tous les problèmes d'intégration
6. Je l'ai vérifié

Par rapport à Subversion, ce qui précède est risible (à part vérifier que vous n'avez pas cassé la construction).

Restrictions aux pratiques de programmation de mon équipe

Ce sont les règles que l'équipe a dû respecter pour que cela fonctionne pour nous. Votre kilométrage peut varier.

1. Une seule personne peut éditer un fichier (Heaven vous aide si elle part en vacances)
2. Ne branchez pas, c'est trop difficile à gérer
3. N'essayez jamais de revenir à une révision précédente

Ce qui peut être fait?

Polarion dispose d'un bon ensemble d'outils pour migrer de sources comme Safe Safe vers Subversion (SVN), qui est la norme de facto actuelle dans la plupart des entreprises pour le contrôle de version open source. Subversion souffre de la nécessité de disposer d'un serveur pour permettre les connexions (contrairement à GIT ou Mercurial qui sont conçus pour les équipes hors ligne distribuées).

Changez votre contrôle de source en SVN / Mercurial / Git et ne regardez jamais en arrière!

Nous l'avons mis hors service il y a environ un an.

Il est arrivé plusieurs fois que ce que j'avais enregistré la veille n'était tout simplement pas là le lendemain matin. Je n'ai pas trouvé ça amusant parce que ça ressemblait étrangement à ce que je n'avais juste pas fini mon travail. Comme j'étais nouveau dans l'entreprise, cela aurait pu être dangereux pour moi.

Nous les avons passés au TFS et cela fonctionne bien depuis.

Mon avis?

Il y en a de meilleurs qui sont plus faciles à utiliser, plus sûrs et totalement gratuits. Pourquoi prendre la peine de l'utiliser du tout?

C'est un domaine de développement où nous avons beaucoup de choix; la plupart, ou tous, mieux que VSS.

• Subversion
• Mercuriel
• Git
• Plus

Utiliser SourceSafe dans une opération commerciale, c'est comme chauffer le bâtiment en brûlant des billets d'un dollar.

En 2000, mon entreprise de huit développeurs a probablement perdu 5 à 10% de sa productivité en raison des corruptions deux fois par jour en moyenne des bases de données VSS. C'était seulement si bas parce que nous étions passés à des sauvegardes toutes les heures.

Depuis que je suis passé de VSS à Perforce, svn et git, je n'ai jamais vu une base de données SCM corrompue.

Je vais peut-être voter pour l'enfer, mais ..

VSS vous met efficacement sous contrôle, dans la mesure où vous ne pouvez pas concilier toute sorte de réalité nécessaire pour réaliser que votre repo maintenant foutu n'était pas de votre faute.

S'il vous plaît, ne l'utilisez jamais.

utilisé pendant des années - c'était la solution par défaut, car elle était déjà là. Si ça m'a mordu plusieurs fois, mais l'inertie est difficile à surmonter

Ensuite, je devais l'utiliser à distance via VPN, et même les enregistrements mineurs étaient comme enfoncer une brique dans un trou d'épingle . Il était plus rapide de trouver manuellement les fichiers modifiés, de les compresser, de les envoyer par e-mail, de les connecter à distance à la machine du coffre-fort source, de les décompresser et d’archiver le code de la machine du coffre-fort source.

Passé à Mercurial. Je peux cloner l'intégralité de la base de code source sur le VPN en moins d'une minute. Et je n'ai plus peur des ramifications.

Jamais de retour.

C'est une abomination. Mais encore mieux que rien.

Je l'ai utilisé pendant une longue période (près de 10 ans) sans jamais rencontrer personnellement de problèmes (y compris au sein des équipes dans lesquelles je travaillais, même si notre code avait tendance à être assez bien divisé pour éviter les conflits, etc.).

Mais il y a beaucoup trop d'histoires de perte de données pour continuer à l'utiliser lorsqu'il existe des alternatives open source décentes et fiables.

Edit: D'après les commentaires, le message semble éviter tout ce qui est complexe (branchement, fusion, conflits) et vous allez probablement bien. Rien de plus et vous vous dirigez vers un territoire à risque.

Même MS le déprécie au profit de TFS.

Pour un magasin solo ou vraiment petit travaillant dans Visual Studio 6 ou quelque chose de plus ancien, c'est passable et mieux que rien. Je pense qu'il y a beaucoup d'exagération sur la gravité de la situation, mais il ne faut alors qu'une seule instance de perdre un travail précieux pour vous aigrir sur un produit (pour une bonne raison). VSS avait sa place, et je le mérite d'avoir au moins encouragé de nombreux développeurs qui n'utilisaient aucun outil SCM à prendre l'habitude, mais comme de nombreuses technologies, il est maintenant à peu près obsolète.

Après 3 ans d'utilisation, en me plaignant de temps en temps à mon manager à cause de toutes les alternatives plus avancées / rationnelles, je n'ai jamais vraiment eu de problème avec VSS, mais je n'ai jamais eu non plus d'option.

Mon point de vue est qu'il suce et souffle à la fois.

La partie la plus ennuyeuse à ce sujet n'est pas son horrible versioning et sa capacité de branchement déroutante, mais la zone de liste dans le menu fichier ne vous permet pas d'appuyer sur la touche flèche droite pour développer.

Vraiment douloureux.

Ma vue sur VSS? J'ai refusé quelques offres d'emploi (très bien rémunérées) car elles demandaient des "compétences VSS". Et je suis sûr qu'il y a quelques autres personnes ici qui ont fait de même.

Non seulement vous souffrez du problème de corruption potentielle de la source (qui devrait être un argument suffisant pour que la direction le remplace), mais vous devez également vivre avec une sauvegarde maladroite et une incapacité à travailler efficacement en équipe sur différents flux de travail.

Trouvez un autre SCM (tout autre) et voyez à quel point les branchements et les fusions peuvent être faciles. Pensez à ces moments où vous avez dû copier des fichiers de votre solution VSS et les conserver ailleurs pendant que vous reveniez pour corriger un bogue sur le code de «production».

Pour commencer, installez simplement GIT - pointez-le sur vos fichiers VSS et voyez combien il est facile pour GASP deux programmeurs de travailler sur différentes parties du même fichier EN MÊME TEMPS, puis demandez au logiciel de fusionner intelligemment vos modifications ... SCM les outils doivent être plus qu'une simple sauvegarde de source.

Mes vues sur VSS? Je l'utilise régulièrement depuis longtemps (toujours utilisé occasionnellement pour des composants plus anciens) mais c'est trop XX siècle pour notre équipe:

• Très peu fiable
• Branches non utilisables
• Prise en charge des versions très médiocre, vous avez des étiquettes mais (tout comme les branches) pas vraiment utilisables

Je suis avec tout ce qui précède: choisissez l'une des meilleures alternatives open source waaaaay (même les anciens CVS) ou, si votre entreprise a une sorte d'abonnement MSDN, TFS .

• son verrouillage par défaut ralentissait les développeurs, et personne ne voulait gâcher sa configuration
• il ne s'intègre pas très bien avec d'autres services, par exemple une application web de gestion de projet
• ça n'allait pas bien fonctionner avec notre serveur CI prévu

Les nouveaux trucs de la Team Foundation 2010 étaient censés aider beaucoup et essayer de s'éloigner des mauvaises parties de VSS. Mais au fond, il repose toujours sur VSS , c'est pourquoi nous sommes passés à SVN.

edit - Je comprends que TFS est tout nouveau, mais lors du test, plusieurs développeurs à qui j'ai demandé avaient des sentiments très similaires. La raison pour laquelle j'ai dit `` à la base '' était parce que je me souviens avoir regardé les fichiers TFS créés dans ma solution qui ressemblaient à ceux créés par VSS. C'est du point de vue du développeur, peut-être même pas au courant de la technologie derrière VSS ou TFS ou tout autre SCM. Désolé pour toute confusion.

À l'époque, j'étais aux prises avec SCCS sous XENIX. VSS, dans Visual Studio 6, pour tous ses échecs et problèmes avait des avantages distincts. Je l'utilise toujours pour de petits projets et je n'utilise plus SCCS dans aucune version.

Je ne peux pas comprendre pourquoi tout le monde veut dénigrer VSS. VSS n'est pas distribué et le contrôle de version distribué est

1. mieux
2. permet un contrôle de version non distribué dans la pratique

Veuillez lire ceci .