SVN contre.Team Foundation Server [fermé]

StackOverflow https://stackoverflow.com/questions/4219

  •  08-06-2019
  •  | 
  •  

Question

Il y a quelques mois, mon équipe a basculé notre contrôle de source vers Apache Subversion depuis Visual SourceSafe, et nous n'avons pas été plus heureux.

Récemment, j'ai regardé Serveur de fondation d'équipe, et au moins en surface, cela semble très impressionnant.Il existe une excellente intégration avec Visual Studio et de nombreux outils intéressants pour les administrateurs de base de données, les testeurs, les chefs de projet, etc.

La différence la plus évidente entre ces deux produits est le prix.Il est difficile de battre Apache Subversion (gratuit).Team Foundation Server est assez cher, donc les fonctionnalités supplémentaires devraient vraiment donner un coup de pied à Subversion.

  • Quelqu'un a-t-il une expérience pratique des deux ?
  • Comment se comparent-ils ?
  • Team Foundation Server en vaut-il vraiment la peine ?
Était-ce utile?

La solution

J'ai récemment rejoint un projet Open Source chez CodePlex.Ils utilisent TFS pour leur contrôle de code source et je dois dire que c'est absolument magnifique.Jusqu’à présent, j’en suis incroyablement impressionné.Je suis un grand fan de l'intégration de l'IDE et de la facilité avec laquelle il est possible de créer des branches et de baliser votre code.Ajouter une solution au contrôle de code source s'effectue en deux clics, si vous avez déjà tout configuré correctement.

Maintenant.Est-ce que cela vaut le prix élevé ?Je ne pense pas.L'avantage de travailler sur des projets chez CodePlex est que cela me permet d'acquérir l'expérience avec TFS dont j'ai besoin, au cas où je devrais l'utiliser quelque part plus tard.Si vous souhaitez une bonne intégration IDE pour votre contrôle de source, allez chercher VisuelSVN package d’intégration.C'est un investissement beaucoup, beaucoup moins cher pour obtenir un grand nombre des mêmes fonctionnalités (gratuitement sur les ordinateurs hors domaine BTW).

Autres conseils

Voici pour moi les plus grandes différences entre les deux, et j'ai utilisé les deux :

1) TFS est assez étroitement couplé à la « méthode de développement Visual Studio ». Cela ne veut pas dire que TFS est étroitement couplé au VS IDE, cela signifie que TFS a du mal à conserver le paradigme familier « enregistrement »/« extraction » de Visual SourceSafe, même s'il ne s'agit plus vraiment d'un modèle approprié.Le concept de "commit"/"update" de Subversion est beaucoup plus réaliste lorsque vous avez des développeurs qui peuvent passer du temps déconnectés du réseau.TFS s'attend à ce que les développeurs soient toujours connectés au serveur.C'est un gros inconvénient.Personnellement, je trouve que TFS est loin d'être transparent sur la façon dont les fichiers sont organisés sur le serveur et sur votre disque local en raison de l'intégration étroite de Visual Studio.Même les plus grands partisans de TFS admettent que son modèle d'enregistrement/départ connecté n'est pas une option convaincante pour les développeurs qui travaillent de manière déconnectée.Dans un climat où les gens commencent à considérer les options DVCS comme git et Mercurial plutôt que SVN, le modèle de « vérification » de TFS ressemble un peu à un dinosaure.

2) Coût. Ceux qui disent que TFS n'est pas cher sont probablement de très petits magasins ou ne respectent pas les conditions de licence de TFS.Vous avez besoin d’une licence d’accès client pour presque tout ce que vous faites.Êtes-vous un manager qui gère uniquement les bugs ?Vous avez besoin d'une CAL d'environ 250 $ (il y en a 5 incluses avec une licence TFS de vente au détail).Un utilisateur professionnel qui souhaite simplement signaler ses problèmes ?Une CAL de 250 $.Un développeur ?250 $ (sauf s'ils ont MSDN, auquel cas c'est inclus).Le serveur?500 $ (inclus si vous avez MSDN).Bien sûr, quelqu'un vous vendant une copie de TFS vous dira que le suivi des éléments de travail est gratuit pour les utilisateurs supplémentaires, mais ces utilisateurs supplémentaires ne peuvent voir que les éléments de travail qu'ils créent eux-mêmes, et non les éléments de travail de toute l'équipe, ce qui n'est pas le cas. trop utile dans un environnement agile et axé sur l’équipe.Tout cela s'additionne lorsque vous avez une organisation de taille moyenne et devient difficile à justifier lorsque le coût supplémentaire de tant de produits haut de gamme comme SVN et CruiseControl.net est de 0 $.(En toute honnêteté envers TFS, j'attends toujours un vraiment bon outil de suivi des problèmes OSS)

3) Structure du projet. Dans les grandes équipes avec un plus petit nombre de projets, TFS fonctionnera probablement bien.Si vous disposez en interne d'un certain nombre de petites applications métiers, non connectées ou faiblement connectées, la structure de TFS peut commencer à devenir autoritaire.D'une part, il n'est pas possible de définir une taxonomie des projets eux-mêmes : vous pouvez créer des « zones » au sein d'un projet, mais tous les problèmes et documents sont suivis ensemble dans le contexte de base d'un « projet ».Créer de nouveaux « projets » prend souvent du temps et est excessif pour de petits efforts.Bien sûr, SVN n'a rien de tel puisqu'il se concentre uniquement sur le contrôle du code source, mais si vous avez besoin d'une bonne flexibilité pour les petits projets, SVN et un autre outil de suivi des problèmes pourraient être un meilleur choix.

Mon avis, pour ce que ça vaut :

  • Pour les grandes équipes avec de gros projets bien budgétisés, dans une boutique Microsoft où les développeurs travaillent presque exclusivement au sein de l'EDI, TFS est le gagnant.TFS est également gagnant lorsque vous devez appliquer une politique de manière centralisée à vos projets.

  • Pour un certain nombre de petites équipes, avec de nombreux projets variés et plus petits, ou des ateliers où le coût est un problème, ou des équipes dont les développeurs travaillent sans contrôle de code source, optez pour SVN.

Je suis surpris que quelqu'un qui a utilisé Subversion dans le passé ait même un désir/un besoin de contrôle de source TFS.

Mon expérience avec TFS (2005) a été assez horrible.J'ai lu toutes sortes de livres blancs et de conseils sur la façon de structurer correctement votre source pour divers besoins de développement.

Notre situation simple, où nous avons un tronc avec le développement principal et une branche d'intégration à partir de laquelle nous intégrons les modifications et les déployons, et une branche de versions pour garder une trace des versions passées, est très courante et simple, mais nous rencontrons continuellement des problèmes.

Mes principaux problèmes avec TFS :

  • La fusion est une DOULEUR par rapport à la subversion.
  • Il y a des bugs non corrigés.J'en ai rencontré un concernant le renommage/fusion qui est connu depuis 2 ans et un correctif ne sera jamais publié pour 2005.Nous avons fini par déplacer notre branche vers un dossier "cassé" et nous l'ignorons maintenant.
  • Mettre des verrous en lecture seule sur vos fichiers est une friction.Qui a dit que je devais modifier des fichiers batch et créer des scripts dans TFS afin qu'il « les vérifie » pour moi ?Subversion sait quels fichiers ont changé.Il n’y a pas de verrous en lecture seule.
  • Vitesse.TFS est très lent sur un WAN, et il n'est vraiment utilisable que si je VPN sur mon ordinateur de travail, ce qui rend mon expérience de développement très lente dans l'ensemble.
  • Manque de bonne intégration de la ligne de commande et de l’explorateur.L'intégration de l'EDI est vraiment utile pour le Get-Latest quotidien, l'ajout de fichiers et l'enregistrement, mais lorsque vous devez effectuer des tâches sur de nombreux projets, il est agréable d'avoir de bons outils à votre disposition.Et avant que quelqu'un ne me saute à la gorge en prétendant que tf.exe fonctionne bien...ce n'est pas vraiment un outil de ligne cmd.Par exemple, l'archivage du code ne devrait pas faire apparaître une boîte de dialogue modale.

...la liste continue.Je pense que même avec toute l’intégration, il existe des alternatives gratuites bien supérieures.

Nous sommes une boutique VS.NET et nous avons implémenté :

  1. Bugzilla pour le suivi des problèmes
  2. Apache Subversion en tant que back-end de référentiel de code source
  3. Serveur VisualSVN pour gérer SVN sur le serveur
  4. TortueSVN (dans l'Explorateur Windows) et AhnkSVN ou VisuelSVN (dans Visual Studio) sur le client
  5. CruiseControl.NET pour les builds automatisés

Coût:Avantages à 0 $:Inestimable

Si vous êtes une petite équipe ou si vous n'êtes pas prêt à adhérer au processus Who TFS, SVN et les outils open source sont la voie à suivre.

Comme d'autres l'ont souligné, TFS vous offre beaucoup plus de fonctionnalités que SVN sous forme de gestion de projet, etc.Ayant utilisé les deux et travaillé avec de très grandes entreprises dans la mise en œuvre de TFS, voici mes deux cents.

1) Si vous utilisez TFS 2005, effectuez une mise à niveau vers TFS 2008.Vous me remercierez.Il y a une tonne d'améliorations dans TFS 2008 qui le rendent fonctionnel.

2) Si vous vivez dans Visual Studio et que vous souhaitez l'intégration IDE, optez pour TFS.J'ai utilisé l'intégration SVN et j'utilise presque toujours TortoiseSVN.

3) Si vous aimez l’idée d’intégrer les comptes à l’authentification Windows, optez pour TFS.La maniabilité de ce côté-là est agréable.Il peut y avoir des crochets pour SVN - je ne suis pas sûr, mais si vous aimez la gestion pilotée par l'interface graphique, TFS est difficile à battre.

4) Si vous avez besoin de suivre des mesures ou de disposer de moyens plus simples de mettre en œuvre des éléments tels que des politiques d'enregistrement, optez pour TFS.

5) Si vous avez des personnes qui ne l’implémenteront pas si ce n’est pas MSFT, optez pour TFS.

6) Si vous faites plus que simplement .NET (travail Java, Eclipse, etc.), optez pour SVN.Oui, il existe de très bons produits (comme Teamprise) qui fonctionnent bien avec TFS.Mais à moins que les autres langues ne représentent une petite partie de votre boutique, restez simplement avec SVN.

En dehors de cela, les fonctionnalités SCM des deux sont à peu près équivalentes.Ils effectuent tous deux des branchements et des fusions, tous deux effectuent des enregistrements atomiques, ils prennent tous deux en charge les renommages et les déplacements.Je pense que pour les personnes qui débutent avec le concept de branchement et de fusion, avoir les branches visibles dans l'Explorateur de contrôle de source est bien.

TFS n'est vraiment pas si cher (1 200 $ peut-être ?).Comparé à SVN, c'est peut-être le cas.L'intégration aux services de reporting et à SharePoint est intéressante, mais encore une fois, si vous ne l'utilisez pas, cela n'a pas d'importance.

Ce que je dirais, c'est de télécharger la version d'essai de 180 jours de TFS et de l'essayer.Exécutez un essai côte à côte.Je pense que tu seras heureux, peu importe la voie que tu prendras.

Comme le souligne Ubiguchi, TFS n'est pas un produit de contrôle de version.Acheter TFS avec l’intention de l’utiliser uniquement pour le contrôle de version serait clairement un gaspillage d’argent.TFS est une suite intégrée d'outils pour automatiser tous les aspects de la gestion du cycle de vie des applications (et plutôt adaptée à « l'entreprise »).

Également selon le message de Ben S – je ne comprends pas votre commentaire sur les verrous.Les verrous ne sont pas du tout requis dans TFS.Les administrateurs peuvent configurer TFS pour qu'il fonctionne comme VSS (fonctionnalités exigées par certains clients "imprudents") pour "Get-Latest on Checkout", ce qui, je crois, effectue également un verrouillage de paiement.

Mais grâce à une utilisation "normale" de TFS, une "extraction" demande à l'utilisateur le type de verrouillage - et la valeur par défaut devrait être "aucun".Un utilisateur PEUT sélectionner un check-out (ou un verrou d'enregistrement) - mais ce n'est pas obligatoire.Si vous ne voulez pas de verrous, ne les utilisez pas.

TFS suit quels utilisateurs ont des extractions sur le serveur pour diverses raisons de performances (rendez-vous plus rapide) et de gestion de projet (j'aime voir quels développeurs ont extrait des fichiers et combien de temps durent leurs extractions).

Je ne suis pas vraiment familier avec SVN (je ne l'ai jamais utilisé) - donc je ne peux pas dire que "la fusion est pire avec TFS" - et je n'ai pas rencontré le bug de fusion signalé par Ben S - mais j'ai eu un super succès avec le branchement et la fusion à l’aide de TFS.

Un cas d'utilisation dans lequel je sais que TFS est encore assez faible concerne les utilisateurs qui sont régulièrement "hors ligne".TFS est un « produit serveur » qui suppose que les utilisateurs sont connectés la majorité du temps.L'expérience hors ligne s'est améliorée dans la version 2008 (elle était lamentable en 2005), mais il reste encore un long chemin à parcourir.Si vous avez des développeurs qui ont besoin (ou souhaitent) d'être souvent déconnectés du réseau pendant de longues périodes, vous feriez probablement mieux d'utiliser SVN.

Une autre fonctionnalité à considérer pour les fans de SVN qui utilisent TFS est la Pont SVN un codeplex qui permet aux utilisateurs d'utiliser TortiseSVN pour se connecter à TFS.Mon bon ami et collègue l’utilise beaucoup et l’adore.

Le commentaire sur le manque de ligne de commande me surprend également : les outils de ligne de commande sont complets (même si beaucoup nécessitent un téléchargement séparé de Outils électriques TFS

Je soupçonne que les commentaires de Ben sont basés sur une évaluation de la version 2005 qui était clairement un produit « Microsoft V1.0 ».Le produit est actuellement en version 2.1 et la version 3 sera prochainement disponible.

TFS est odieux.À ce stade, je contrôle la version localement en utilisant SVN (avec Live Mesh pour les sauvegardes) car j'ai de nombreux problèmes avec TFS.Le principal problème est que TFS utilise des horodatages pour enregistrer si vous disposez de la dernière version et stocke ces horodatages sur le serveur.Vous pouvez supprimer votre copie locale, obtenir la dernière version de TFS et il indiquera que tous les fichiers sont à jour.C'est un système idiot qui ne vous donne aucune garantie que vous disposez de la bonne version des fichiers.Cela entraîne de nombreux désagréments :

  • TFS doit être informé lorsqu'un fichier est modifié, vous devez donc être connecté au serveur à tout moment.
  • TFS est confus si vous modifiez des fichiers en dehors de l'EDI.De plus, il définit tous les fichiers en lecture seule dans NTFS.

Bien que TFS prenne en charge la fusion, il s’agit en réalité d’un système d’enregistrement/extraction.Si vous modifiez un fichier, vous constaterez souvent qu'il est verrouillé pour les autres développeurs.Il existe des moyens de contourner ce problème, mais le système est tellement compliqué que vous rencontrerez toujours le problème.Par exemple, nos développeurs ont découvert qu'ils pouvaient contourner la définition de tous les fichiers en lecture seule dans NTFS en consultant une solution complète, qui définit un verrou exclusif sur tous les fichiers.Je l'ai fait plusieurs fois car Subversion a la même syntaxe pour l'extraction, qui n'acquiert pas de verrou.

Enfin, Team Explorer (le client) fait 400 Mo, le serveur TFS nécessite SharePoint et deux jours pour l'installer.Le programme d'installation de Subversion en un clic fait environ 30 Mo et installera le serveur pour vous en moins d'une minute.TFS possède de nombreuses fonctionnalités, mais ses fondations sont si fragiles que vous ne les utiliserez jamais ou ne vous en soucierez jamais.TFS coûte cher en termes de licence, et avec le temps, les développeurs perdront du temps à déclamer sur stackoverflow au lieu d'écrire du code :P

Ma recommandation, Team System ne vaut pas son prix.J'ai utilisé les deux et après avoir utilisé Team System, j'ai essayé de trouver un remplacement similaire.Fondamentalement, ce que vous payez, c'est l'intégration et vous pourriez discuter du support de personnalisation, mais j'ai pu créer un remplacement de Team System avec un peu de temps et intégrer des outils ensemble.

j'ai récemment posé une question sur ce que d'autres ont fait pour proposer une alternative au Team System.Je liste également les outils de développement que j'ai utilisés pour créer le remplacement.J'espère qu'avec cette réponse et la question que j'ai posée, vous pourrez trouver ce qui fonctionne pour vous.

Je ne déteste pas le Team System, je ne pense tout simplement pas que cela en vaut la peine.C'est un très bon outil et si cela ne vous dérange pas d'en payer le prix, alors utilisez-le par tous les moyens.C’est la raison pour laquelle j’ai créé le remplacement que j’ai proposé.Je voulais la fonctionnalité fournie par Team System.

Voici une version open source de VisualSVN appelée Ankhsvn.C'est bien mieux maintenant que Collabnet a pris le relais.

Si tout ce dont vous avez besoin est un contrôle de code source, TFS est excessif.L'un de mes précédents employeurs avait TFS, VSS et Subversion dans son entreprise.Nous n'avions pas Active Directory ou Exchange Server 2003 dans notre entreprise, nous avons donc fini par créer des utilisateurs distincts sur le serveur TFS afin que les développeurs puissent l'utiliser.Nous avons eu le même genre de problèmes de fusion que ceux mentionnés par Ben Schierman, ainsi que d'autres comportements bogués qui nous ont poussés vers Subversion.

Que TFS soit la bonne solution pour vous dépendra en partie de votre budget, de la taille de votre équipe de développement, ainsi que du temps et du personnel disponibles pour la configuration/maintenance de votre solution.Si vous souhaitez bénéficier des fonctionnalités supplémentaires de suivi des problèmes, d'éléments de travail et de statistiques de projet fournies par TFS, cela vaut peut-être la peine d'envisager d'autres alternatives.Des produits comme JIRA (d'Atlassian Systems) ou Trac s'intègrent bien à Subversion et offrent le type de surveillance qu'un chef de projet ou de programme pourrait offrir à un prix inférieur.

Dans un environnement idéal, avec Active Directory, Exchange Server 2003 ou version ultérieure et un personnel dédié au référentiel, TFS est plus susceptible d'être un bon choix.

Je l'ai utilisé aussi bien au travail qu'à la maison.Ils sont tous les deux très cool en eux-mêmes.La seule fois où je recommanderais d’utiliser TFS, c’est si vous utilisez plus de fonctionnalités que le simple contrôle de source.Si tout ce dont vous avez besoin est un contrôle de code source, vous ne pouvez pas vous tromper avec SVN et c'est pourquoi.

  1. Serveur VisualSVN Il s'agit d'un serveur SVN complet avec un joli plugin pour le gérer.Il vous permet d'utiliser l'authentification Windows directement via l'interface utilisateur.Facile.

  2. Tortue C’est une tortue, c’est assez dit.

  3. ankhsvn C'est un excellent plugin SCC.Pour ceux qui souhaitent une intégration complète de VS IDE, la dernière version est un plugin SCC complet.Vous bénéficiez donc désormais d’une intégration complète et gratuite.

La configuration ci-dessus est 100 % gratuite et vous permettra d'effectuer tout ce dont vous avez besoin pour le contrôle des sources.

TFS ne concerne pas seulement le contrôle de code source.Si vous utilisez l'ensemble du package proposé par TFS, le suivi des bogues, les builds, les rapports, etc., alors TFS est un choix assez solide (certainement meilleur que Rational).TFS s'intègre également bien à Active Directory.

Mais si vous parlez uniquement de SCM, je préfère SubVersion.Je n'aime pas vraiment l'intégration IDE.J'aime aussi la convention SVN de structure Trunk/Tags/Branches et la relative facilité de basculement entre les branches.La fusion semblait cependant plus facile dans TFS.L'interface utilisateur de Tortoise bat haut la main celle de TFS, notamment en ce qui concerne l'ajout d'un fichier à un dépôt.

Je dirais que cela dépend vraiment de vos besoins.TFS est très bien, je l'ai beaucoup utilisé, mais il est très destiné au niveau de l'entreprise, si vous n'avez pas besoin de toutes ces fonctionnalités, cela n'est peut-être pas nécessaire.Si vous avez besoin de ces fonctionnalités (en particulier le branchement, l'évolutivité, le suivi des éléments de travail, etc.), elles valent chaque centime.Gardez à l'esprit que TFS inclut le suivi des bogues, le suivi des éléments de travail et d'autres fonctionnalités au-delà du contrôle de source.Si vous avez plusieurs branches ou si vous vous retrouvez confronté à un manque de fonctionnalités ou autre dans Subversion, cela pourrait être une bonne idée de changer.Mais à moins d’avoir une bonne raison de changer, vous devriez probablement éviter les coûts et la productivité liés au changement de système de contrôle de source.

Après avoir largement utilisé les deux, je pense que Wedge avait raison en notant que "TFS inclut le suivi des bogues, le suivi des éléments de travail et d'autres fonctionnalités au-delà du contrôle de source".

Cependant, je peux honnêtement dire que SVN et TFS semblent assez égaux en termes d'évolutivité, et que le contrôle de code source de SVN a l'avantage sur TFS en raison de sa simplicité inhérente.

Si vous souhaitez un suivi des éléments de travail et des bogues parallèlement à votre contrôle de code source, vous optez soit pour TFS, soit pour SVN et d'autres outils, éventuellement gratuits, tels que bugzilla.Bien que TFS intègre à la fois le contrôle de source et le suivi des éléments de travail, je pense honnêtement que MS aurait dû le donner gratuitement en guise d'excuses pour avoir abusé de tant de développeurs avec VSS au fil des ans.

J'ai utilisé à la fois SVN et TFS.Le principal avantage de l'utilisation de TFS est son intégration étroite avec Visual Studio.Le suivi des bogues et le suivi des tâches seront tous regroupés au même endroit.Et les rapports générés pour ces éléments aideront les parties prenantes à se tenir informées de l'état du projet.

Je travaille sur un projet avec 5 personnes et nous sommes récemment passés de SVN à TFS.L’ensemble du processus a été un cauchemar.Nous avons du code généré automatiquement à partir de XMLSpy et TFS ne reconnaît pas les fichiers modifiés en dehors de VS2008.Les outils électriques TFS peuvent analyser votre paiement et résoudre ce problème, mais il est pénible de devoir se rappeler d'utiliser ces outils.Un autre problème que nous rencontrons constamment est l'outil de fusion par défaut dans TFS.C'est de loin le pire outil de fusion que j'ai jamais utilisé.On pourrait penser que TFS serait capable de gérer des fusions de solutions de base, mais jusqu'à présent, cela n'a pas été le cas.

L'interface utilisateur intégrée est très utile, mais elle présente également des défauts.Si je vérifie depuis mon explorateur de solutions, il arrive parfois que les fichiers qui ont été ajoutés ne soient pas extraits.Si je le fais depuis la fenêtre Team Source Control, cela fonctionne parfaitement.Pourquoi donc?J'attends avec impatience TFS dans VS2010 car j'en ai entendu de bonnes choses, et SVN est loin d'être parfait, mais je m'attendais à ce que certaines de ces fonctionnalités fonctionnent un peu plus intuitivement.

Adam

TFS est idéal pour la gestion et le suivi de projets, mais je pense que le contrôle des sources n'est pas aussi bon que SVN.Voici mes problèmes avec TFS :

Modèle d'arrivée/départ

C'est un énorme inconvénient pour le contrôle de source TFS.Malheureusement, VS extrait automatiquement les éléments pour vous, même si vous ne le souhaitez pas.J'ai été dans une situation où quelqu'un a vérifié certains fichiers puis est parti en vacances.J'étais chargé de restructurer la structure des répertoires, mais je n'y suis pas parvenu car de nombreux fichiers ont été extraits par cette personne.Il n'y a aucun moyen dans l'interface graphique d'annuler l'extraction, ce qui signifie qu'elle doit être effectuée une par une dans la ligne de commande.Ou j'ai dû trouver comment écrire un script Power Shell pour cela.

VS est tenu de tout faire

Parfois, je souhaite modifier un fichier texte et l'archiver.Cela m'oblige à démarrer VS 2010, qui est une énorme bête, juste pour modifier un fichier et l'archiver.Quelque chose qui prenait quelques secondes avec SVN me prend maintenant une minute.

Comme d'autres l'ont souligné, les fichiers sont marqués en lecture uniquement s'ils ne sont pas extraits.Si vous le rendez accessible en écriture et le modifiez en dehors de VS, TFS ne le reconnaîtra pas.Cela rend l'édition de quelque chose en dehors de VS ennuyeux.Cela signifie lancer VS, extraire le fichier, le modifier dans un autre éditeur, s'enregistrer dans VS.

Certaines opérations qui étaient faciles dans SVN sont maintenant pénibles

  • Peut-être que je ne l'ai pas encore compris, mais j'ai trouvé que restaurer un ensemble de modifications était très fastidieux avec TFS.

  • L'ajout de fichiers au contrôle de code source, qui ne font pas partie d'une solution, est très pénible.L'explorateur de contrôle de source TFS affiche uniquement quels fichiers sont sous contrôle de source, pas lesquels ne le sont pas (il existe peut-être un paramètre quelque part pour cela, je ne sais pas).Avec Tortoise SVN, je pouvais simplement appuyer sur Commit sur un dossier et sélectionner les fichiers à ajouter.

Je dirige actuellement les efforts visant à évaluer TFS dans mon entreprise par rapport à Rational Suite, que nous utilisons actuellement.Jusqu'à présent, TFS 2008 utilise clearcase + clearquest.L'intégration de l'environnement de développement est là où elle brille vraiment.

Mes 10 centimes :

TFS2005 était une blague - difficile à installer et encore plus difficile à entretenir TFS2008 était stable - plus facile à installer, une maintenance plus simple et des versions automatisées qui fonctionnent.TFS2010 est ÉPIQUE !- L'installation est facile.La gestion est très simple ;c'est une interface utilisateur bien présentée.L'intégrer à VS2008 n'est pas si simple puisque vous ne pouvez pas créer de projets dans vs2008, vous devez utiliser vs2010 (ce qui est stupide).TFS2010 vous permet également de modifier l'emplacement du projet sharepoint au lieu d'avoir ces horribles sous-dossiers de TFS2008.TFS2010 dispose également d'outils comme un graphique d'avancement qui sont très utiles pour la gestion de projet.C'est comme si TFS2010 s'adressait à toute l'équipe de production, y compris les clients !Mais ça coûte quand même beaucoup trop cher :(

Gardez également à l’esprit que TFS nécessite BEAUCOUP plus de puissance de la part du matériel du serveur.Et au minimum une licence de serveur Windows bien sûr.

La meilleure pratique, comme notre entreprise l'a suivie, consiste à utiliser 2 serveurs :front-end (avec sharepoint intégré) et un serveur SQL dédié en back-end (nous utilisons un cluster d'entreprise).TFS peut être installé sur 1 machine, mais ne devrait pas l'être.

En comparaison, notre serveur svn est installé sur un serveur Linux virtuel avec 256 Mo de RAM et 1 processeur, et est toujours plusieurs fois plus rapide lors de l'exécution de tâches courantes telles que le paiement de tout.Le matériel virtuel était le plus bas que Vshpere pouvait attribuer !Le disque est cependant rapide (SAN).

Je dirais que TFS nécessite un matériel dédié pour au moins 5 000 $, tandis que le serveur svn (sous Linux) peut fonctionner avec n'importe quel matériel obsolète pour le système d'exploitation Windows actuel.

À mon avis, cela dépend de la situation et de l'environnement dans lequel le projet est réalisé.Si vous avez juste un petit projet simple, alors SVN est génial.Comme certains l'ont déjà écrit, VisualSVN s'intègre parfaitement dans Visual Studio s.t.vous n'avez pas besoin d'effectuer l'enregistrement/extraction sur le système de fichiers natif.

TFS est idéal pour le contrôle de version, mais encore mieux si vous utilisez réellement toutes ses capacités.À mes yeux, cela vaut vraiment la peine si vous utilisez - par exemple - les éléments de travail comme référentiel intégré pour gérer les rapports de bugs des clients, les demandes de nouvelles fonctionnalités et pour suivre l'avancement de votre projet en gérant les tâches et le temps estimé, le temps utilisé et le temps d'utilisation correspondant. indications du temps restant.
Ce qui est également très intéressant, c'est d'utiliser la fonctionnalité d'association d'éléments de travail aux checkins du code source.Voir ici pour plus d'informations à ce sujet.

Nous sommes une petite équipe en train de migrer de SVN vers TFS2010.Notre principale raison de le faire est l'intégration dans Visual Studio et WebAccess pour le suivi des bogues, qui fait désormais partie de TFS.

@Adam:J'espère que nous aurons une meilleure expérience.Je ne peux pas encore le dire...

J'ai utilisé SVN au cours des 3 dernières années (venant de VSS plus tôt) et j'ai récemment dû passer à TFS2010.Le sentiment général est qu'il est plus bogué que SVN et, à l'exception de la belle intégration avec les tâches/bugs, je ne le vois pas comme ayant un avantage sur SVN.La vitesse semble également être un peu plus lente qu'avec SVN.

Si je devais choisir un contrôle de source maintenant, j'opterais toujours pour SVN.

Concernant les outils :- Ankhsvn Visual Studio Plugin est aussi bon que le contrôle source TFS - Tortoise est bien meilleur que l'homologue TFS

TFS est génial, si vous n'avez pas besoin de non-développeurs, pour accéder aux trucs pm.

Notre service d'assistance doit être impliqué dans le processus, et cela n'a tout simplement pas suffi.

De plus, la gestion des builds dans TFS 2005 au moins est intéressante, et elle ne peut même pas être construite par rapport aux slns 2008.Je n'aime vraiment pas que mon choix de contrôle de code source affecte mes choix de déploiement, c'est pourquoi mon équipe n'est pas une boutique SVN.

Si ça juste basé sur le contrôle de source, j'opterais pour SVN.Le complément gratuit AnkhSVN pour Visual Studio a été considérablement amélioré dans sa nouvelle version.De plus, vous obtenez le code source de SVN et la documentation est excellente !Ils ont changé des choses obscures dans TFS 2010 Source Control, et sans le code source, le dépannage peut être très intimidant.De plus, vous dépendez de l'équipe MSDN pour produire les documents et ils le font selon leur propre calendrier et selon leur propre profondeur.

Cela étant dit, TFS offre évidemment bien plus que le contrôle de code source.C'est un ALM outil.Le combiner avec des éléments de travail, des rapports, des builds automatisés, enregistrement sécurisé, tests automatisés, etc.peut fournir une valeur très riche que vous ne pouvez obtenir qu'en connectant des outils disparates avec SVN.Et bien sûr, avoir les sources de SVN n’est pas une sécurité.Je me suis retrouvé dans des scénarios avec SVN où il aurait fallu des semaines pour comprendre totalement ce qui se passait.

Je vous recommande donc de l'examiner du point de vue ALM et de voir si votre entreprise va utiliser toutes les fonctionnalités de TFS ou va le faire avec une stratégie de pointe (par ex.JIRA).

TFS à un kilomètre et demi.

Par inadvertance, je me cause trop de problèmes avec l'approche basée sur les fichiers SVN.Problèmes de contrôle de source que j'ai rencontrés :TFS - 0 Problèmes sur 2 ans SVN - Perdre le compte ...

Oui, je sais que le prix de TFS en tient compte pour la plupart des entreprises, ce qui est vraiment dommage.MS pourrait avoir beaucoup plus de parts de marché (et de bénéfices) s’ils disposaient d’un modèle de tarification raisonnable.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top