Alternative au VSS pour un one man show (armée d'un seul ?)

Question

Je programme depuis plus de 10 ans maintenant pour le même employeur et le seul contrôle de code source que nous ayons jamais utilisé est VSS.(Désolé, c'est ce qu'ils avaient quand j'ai commencé).Nous n'avons jamais été que quelques-uns ;deux en ce moment et nous travaillons généralement seuls, donc VSS a bien fonctionné pour nous.Alors, j'ai deux questions :1) Devrions-nous passer à autre chose comme Subversion, git, TFS, etc., quoi exactement et pourquoi (s'il vous plaît) ?2) Suis-je au-delà de tout espoir et destiné à la damnation éternelle parce que VSS m'a corrompu (comme le dit Jeff) ?

Wow - merci pour toutes les excellentes réponses !

Il me semble que je devrais clarifier certaines choses.Nous sommes une boutique MS (partenaire Gold) et nous effectuons principalement du travail VB, ASP.NET, SQL Server, sharepoint et Biztalk.J'ai un diplôme CS, j'ai donc fait de l'assemblage x86 C, C++ sur DEC Unix et Slackware Linux dans un "temps perdu"...

Mon souci avec VSS est que maintenant je travaille beaucoup plus sur un VPN et les performances de VSS et j'ai peur que notre base de données VSS version 5 de plus de 10 ans soit choisie...Il existe le service LAN qui est censé accélérer les choses, mais je ne l'ai jamais utilisé et je ne suis pas sûr qu'il aide à lutter contre la corruption. Quelqu'un a-t-il utilisé le service LAN VSS ?(nouveau avec VSS 2005)

Answer 1

J'opterais probablement pour Subversion, si j'étais vous.Je suis un fanatique total de Git à ce stade, mais Subversion présente certainement certains avantages :

• simplicité
• abondance d'outils interopérables
• communauté active et solidaire
• portable
• A une très bonne intégration du shell Windows
• s'intègre à Visual Studio (je pense - mais sûrement via un tiers)

Git présente de très nombreux autres avantages, mais ceux ci-dessus ont tendance à être ceux qui intéressent les gens lorsqu'ils posent des questions générales comme celles-ci.

Modifier:l'entreprise pour laquelle je travaille actuellement utilise le serveur VisualSVN, qui est gratuit.Cela rend la configuration d'un référentiel Subversion sur un serveur Windows très simple, et sur le client, nous utilisons TortoiseSVN (pour l'intégration du shell) et AnkhSVN pour la prise en charge de Visual Studio.C'est plutôt bien et devrait être assez facile à comprendre, même pour les utilisateurs de VSS.

Derniers jours Modifier:Donc... près de huit ans plus tard, je ne recommanderais jamais Subversion à qui que ce soit, pour quelque raison que ce soit.Je ne me rétracte pas vraiment, en soi, parce que je pense que mon conseil était valable à l'époque.Cependant, en 2016, Subversion ne conserve quasiment aucun des avantages qu’il avait par rapport à Git.Les outils pour Git sont supérieurs (et beaucoup plus diversifiés) à ce qu'ils étaient autrefois, et en particulier, il existe GitHub et d'autres bons fournisseurs d'hébergement Git (BitBucket, Beanstalk, Visual Studio Online, juste au-dessus de ma tête).Visual Studio dispose désormais d'un support Git prêt à l'emploi, et c'est en fait plutôt bon.Il existe même des modules PowerShell pour offrir une expérience Windows plus native aux utilisateurs de la console.Git est encore plus facile à configurer et à utiliser que Subversion et ne nécessite aucun composant serveur.Git est devenu aussi omniprésent que n'importe quel outil, et vous ne feriez que vous tromper si vous ne l'utilisiez pas (à moins que vous ne vouliez vraiment utiliser quelque chose qui n'est pas Git).Ne vous méprenez pas, ce n'est pas que je déteste Subversion, mais plutôt que je reconnais que c'est un outil d'une autre époque, un peu comme un rasoir droit pour se raser.

Answer 2

On dirait que SubVersion est le gagnant ici.Je te ferais une faveur et j'utiliserais Serveur VisualSVN.C'est gratuit et vous évitera bien des maux de tête lors de l'installation.

Answer 3

Si vous êtes habitué au fonctionnement de VSS, consultez (sans jeu de mots) Le coffre-fort de Sourcegear.C'est un excellent moyen de migrer loin de VSS car il est livré avec l'intégration IDE et prend en charge l'extraction/l'enregistrement, mais lorsque vous êtes prêt et que vous vous sentez à l'aise, vous pouvez également passer au style de programmation de validation de mise à jour d'édition trouvé dans SVN.

Il est gratuit pour les développeurs individuels, fonctionne sur IIS et est construit sur .net, il devrait donc s'agir d'une pile assez familière vers laquelle vous pouvez basculer.

Answer 4

Quoi que vous fassiez, ne changez pas pour le plaisir de changer.

Si cela fonctionne pour vous et que vous ne rencontrez aucun problème, je ne vois aucune raison de changer.

Answer 5

Pour ce que ça vaut, Perforce est une option potentielle si vous vous en tenez vraiment à 1 ou 2 utilisateurs.La documentation actuelle de Perforce indique que vous disposez de 2 utilisateurs et de 5 clients sans avoir à commencer à acheter des licences.

Vous pourriez avoir des raisons de passer à Forforce en fonction de votre flux de travail et si vous avez besoin de créer des branches de la même manière.N'étant pas très familier avec certains autres produits mentionnés ici, je ne peux pas vous dire comment se compare nécessairement le département des fonctionnalités pour des choses comme les branchements, etc.

C'est rapide et cela a été solide comme un roc pour nous (plus de 300 développeurs sur une base de code vieille de plus de 10 ans).Nous stockons plusieurs T d'informations et cela a été assez réactif.Avec un petit nombre d'utilisateurs, je doute que vous rencontriez de nombreux problèmes de performances en supposant que vous disposiez d'un bon matériel pour votre serveur.

Ayant déjà utilisé VSS, je pense que vous pouvez tirer tellement d'avantages d'un meilleur système SCM que le changement doit être envisagé, que vous soyez corrompu ou non.Le branchement seul pourrait en valoir la peine pour vous.Un véritable modèle client/serveur, de meilleures interfaces (par programme et en ligne de commande) sont quelques autres éléments qui pourraient vraiment aider à améliorer votre flux de travail et à améliorer quelque peu la productivité.

En résumé, mon point de vue sur Perforce est le suivant :

• C'est rapide et assez fiable
• De nombreux outils clients multiplateformes (windows, unix, mac, etc.)
• c'est gratuit pour 2 utilisateurs et 5 clients
• S'intègre au studio de développement (et à d'autres outils)
• Possède un système de branchement puissant (qui peut ou non vous convenir).
• Possède plusieurs interfaces scriptables (python, perl, ruby, C++)

Certainement YMMV - je propose cette alternative uniquement comme quelque chose qui pourrait valoir la peine d'être étudié.

Answer 6

J'ai récemment commencé à utiliser Mercuriel pour certains de mes travaux.C'est un système distribué comme Git mais qui semble plus facile à utiliser et bien mieux pris en charge sous Windows, ce dernier étant crucial pour moi.

Avec le contrôle distribué du code source, chaque utilisateur dispose d'une copie locale complète du référentiel.Si vous êtes la seule personne à travailler sur un projet, comme vous le dites souvent, cela peut beaucoup simplifier les choses puisque vous créez simplement votre propre référentiel et effectuez tous vos commits, etc.localement.Si vous souhaitez faire appel à d'autres développeurs plus tard, vous pouvez simplement transférer l'intégralité du contenu de votre référentiel - les versions actuelles et tout l'historique - vers un autre système, soit sur un serveur partagé, soit directement sur le poste de travail d'un autre utilisateur.

Si vous travaillez uniquement avec un référentiel local, n'oubliez pas que vous aurez également besoin d'une solution de sauvegarde car il n'y a pas de copie de tout votre code sur un serveur partagé.

Je pense que Mercurial présente de nombreux autres avantages par rapport à Subversion, mais il présente un gros inconvénient qui a déjà été mentionné comme un avantage de Subversion :il y a un beaucoup d'outils tiers et d'intégrations pour Subversion.Comme Mercurial n'existe pas depuis aussi longtemps, le choix est bien moindre.Sous Windows, il semble que vous deviez soit utiliser la ligne de commande (mon choix), soit le TortueHg Intégration de l'Explorateur Windows.

Answer 7

VSS est horrible.Je canalise peut-être Spolsky (je ne sais pas s'il a dit cela), mais utiliser VSS est en fait pire que de ne pas utiliser du tout le contrôle de source.Malgré son nom, il n'est-ce pas sûr.Cela crée l’illusion de sécurité sans la fournir.

Sans VSS, vous feriez probablement des sauvegardes régulières de votre code.Avec VSS, vous penserez : « Mehh, c'est déjà sous contrôle de code source.Pourquoi s'embêter à sauvegarder ? Génial jusqu'à ce qu'il corrompt toute votre base de code et tu perds tout.(Cela s'est d'ailleurs produit dans une entreprise dans laquelle je travaillais.)

Débarrassez-vous de VSS dès que possible et passez à une véritable solution de contrôle de source.

Answer 8

Ne vous inquiétez pas de la corruption de VSS, mais plutôt de la corruption de vos données par VSS.Son bilan n'est pas bon dans ce domaine.

Sauvegardez fréquemment si vous ne passez pas à un autre système de contrôle de version.Les sauvegardes devraient être effectuées quotidiennement, même avec d'autres SCM, mais c'est doublement important avec VSS.

Answer 9

J'aime utiliser Subversion pour mes projets personnels.Je pourrais parcourir la liste des fonctionnalités et prétendre que cela apporte beaucoup de choses que d'autres systèmes de contrôle de source n'apportent pas, mais il y en a des tonnes de bonnes et les bons choix sont vraiment une question de style.Si vous vous enregistrez après chaque petit changement (c.-à-d.un enregistrement par changement de fonction), plusieurs personnes peuvent alors travailler sur le même fichier source avec un très faible risque de conflits de fusion dans pratiquement n'importe quoi mais VSS (je n'ai pas utilisé VSS depuis des années, mais d'après ce dont je me souviens, une seule personne à la fois peut travailler sur un fichier.) Si cela ne vous arrive jamais, j'ai l'impression que la meilleure solution est de utilisez ce que vous savez.VSS vaut mieux que pas de contrôle de source du tout, mais cela me semble restrictif ces jours-ci.

Je ne pense pas que vous soyez au-delà de tout espoir parce que vous demandez s'il serait préférable de changer ;vous êtes au-delà de tout espoir lorsque la réponse est évidente et que vous ignorez les preuves.

Même si vous ne changez pas de système de contrôle de code source, vous devriez en choisir un comme SVN ou git et passer quelques semaines à le lire et à créer un petit projet en l'utilisant ;cela aide toujours à affûter la scie.

Answer 10

Je ne suis pas d'accord avec les gens qui disent que si vous n'avez pas de problèmes, vous feriez mieux de ne pas changer.

Je pense que le SCM fait partie des disciplines qu'un bon développeur devrait bien connaître, et franchement, même si vous maîtrisez VSS, vous n'expérimentez qu'une petite fraction des avantages qu'un bon outil SCM et une bonne stratégie SCM peuvent apporter pour vous et votre équipe.

Évidemment, évaluez et testez les alternatives d’abord dans un environnement hors production.

Answer 11

Au travail, nous utilisons Subversion avec TortoiseSVN - fonctionne très bien mais c'est philosophiquement différent de VSS (pas vraiment un problème s'il n'y a que vous mais cela vaut la peine d'en être conscient).J'aime vraiment le fait que l'ensemble du référentiel ait un numéro de révision.

Si j'avais eu le libre choix, j'aurais probablement opté pour Vault, mais à l'époque, je n'avais aucun budget.

Je regarde des choses pour un usage personnel.Il y a des raisons d’utiliser Subversion et des raisons d’utiliser quelque chose de complètement différent.Les alternatives que j'envisage sont Vault (comme auparavant, gratuite à usage unique) et Bazaar.GIT J'ai dû le rejeter car je suis, sans vergogne, un utilisateur de Windows et pour le moment, GIT ne l'est tout simplement pas.

La nature distribuée de GIT et l'option d'enregistrements privés/temporaires (en supposant que j'ai compris ce que j'ai lu) est attrayant - d'où mon regard sur Bazaar.

Mise à jour: J'ai creusé et joué un peu plus et j'ai en fait opté pour Mercurial pour un usage personnel, l'installation intégrée avec TortoiseHg rend les choses très simples et cela semble être bien considéré.J'essaie toujours de trouver comment forcer un miroir automatique des commits sur un serveur et il semble y avoir quelques limitations mineures à la fonction ignorer, mais elle fait bien le travail jusqu'à présent...

Murph

Answer 12

Je dirais de s'en tenir à ce qui fonctionne pour vous.Sauf si vous rencontrez des problèmes avec VSS, pourquoi changer ?Subversion est génial, bien qu'un peu compliqué pour commencer à l'utiliser.TFS est bien meilleur que VSS, même s'il est assez cher pour une si petite équipe.Je n'ai pas utilisé git donc je ne peux pas vraiment en parler.

Answer 13

J'ai utilisé vss pendant des années jusqu'à ce que je passe à svn il y a environ deux ans.mes plus grandes plaintes concernant vss concernaient les mauvaises performances du réseau (ce problème est peut-être résolu maintenant) et le verrouillage pessimiste des fichiers.svn a résolu les deux, est facile à configurer (j'utilise le serveur collabnet et le client tortoisesvn, bien qu'il existe deux bons plugins Visual Studio :visualsvn - commercial et ankhsvn - open source), facile à utiliser et à administrer, et bien documenté.

il est tentant de dire "si ce n'est pas cassé, ne le répare pas", mais vous apprendrez un outil de contrôle de source plus moderne et, peut-être plus important encore, de nouvelles façons d'utiliser le contrôle de source (par ex.branchements et fusions plus fréquents) que le nouvel outil prendrait en charge.

Answer 14

Si vous n'avez que 2 personnes et que vous travaillez principalement de manière indépendante, git vous offrira beaucoup plus de flexibilité, de puissance et sera de loin le plus rapide avec lequel travailler.

C'est cependant une douleur dans le dos à utiliser.En utilisant VSS, vous programmez évidemment pour Windows - si vous faites des trucs sur l'API Win32 en C, alors git sera une courbe d'apprentissage mais sera très intéressant.

Si vos connaissances approfondies ne s'étendent toutefois qu'à ASP et Visual Basic, utilisez simplement Subversion.Marchez avant de pouvoir courir.

** Je n'essaie pas de dire que si vous ne connaissez que VB, vous êtes stupide ou quelque chose comme ça, mais ce git peut être très pointilleux et pointilleux à utiliser (si vous avez utilisé WinAPI en C, vous savez tout sur pointilleux et capricieux), et vous souhaiterez peut-être une introduction plus progressive au SCM que celle proposée par git

Answer 15

Si vous êtes un one man show et strictement une boutique Microsoft, alors Coffre SourceGear est certainement également un candidat de choix pour le changement.

Caractéristiques:

• Gratuit pour un seul utilisateur, idéal pour vous
• Il utilise SQL Server pour son backend, la fiabilité des données est donc énorme
• Il a des enregistrements atomiques, tous les fichiers archivés en même temps sont organisés en groupe et sont appelés un ensemble de modifications.
• Intégration VisualStudio.
• Dispose d'un outil d'importation depuis SourceSafe, vous pouvez donc conserver votre historique
• Le client communique avec le serveur via HTTP, donc l'accès à distance à la source en dehors du bureau peut être configuré très facilement et fonctionne bien, car ils ne transfèrent que les deltas des modifications soumises et reçues.Vous pouvez utiliser SSL pour sécuriser la connexion.

Je considérerais certainement cela comme une option.

Answer 16

Si vous souhaitez un cycle de vie complet dans un seul package, vous souhaiterez probablement consulter Visual Studio Team System.Il nécessite un serveur, mais vous pouvez obtenir un "Action Pack" de MS qui inclut toutes les licences dont vous avez besoin pour "Team Foundation Server Workgroup Edition" à partir du Centre des partenaires.

Avec cela, vous obtiendrez un suivi des bogues, des risques et des problèmes ainsi que de nombreuses autres fonctionnalités :)

• Contrôle des sources
• Suivi des éléments de travail (exigences, bogues, problèmes, risques et tâches)
• Création de rapports sur les données de votre projet (suivi des éléments de travail, build, checkins et plus dans un seul qube)
• Analyse du code
• Tests unitaires
• Test de charge
• Analyse de performance
• Construction automatisée