SVN vs Team Foundation Server

Question

Il y A quelques mois mon équipe passés de notre contrôle à la source sur Apache Subversion à partir de Visual SourceSafe, et nous n'avons pas été plus heureux.

Récemment, j'ai été à la recherche à Team Foundation Server, et au moins sur la surface, il semble très impressionnant. Il s'agit de la grande intégration avec Visual Studio, et beaucoup de grands outils pour les Administrateurs de base de données, testeurs, 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, les fonctions supplémentaires serait vraiment le coup de Subversion dans le pantalon.

• Quelqu'un aurait-il une expérience pratique avec les deux?
• Comment se comparent-ils?
• Est Team Foundation Server effectivement en vaut la peine?

Answer 1

Ici sont les plus grandes différences entre les deux pour moi, et je l'ai utilisé à la fois:

1) TFS est plutôt étroitement couplée à de la "Visual Studio manière" de faire du développement. Cela ne veut pas dire que TFS est étroitement couplée pour la VS IDE, cela signifie que TFS lutte pour garder le familier "check in"/"check out" paradigme de Visual SourceSafe, même lorsque ce n'est vraiment pas un modèle approprié plus. La Subversion de la notion de "valider"/"mise à jour" est beaucoup plus réaliste lorsque vous avez des développeurs qui pourraient passer du temps déconnecté du réseau. TFS s'attend à des développeurs d'être toujours connecté au serveur. C'est un gros moins. Personnellement, je trouve TSF pour être moins transparent sur la façon dont les fichiers sont organisés sur le serveur et sur votre disque local en raison de l'étroite intégration de Visual Studio. Même TFS est plus gros promoteurs de concéder que la connexion check-in/check-out modèle n'est pas une option intéressante pour les développeurs qui travaillent déconnecté. Dans un climat où les gens commencent à chercher des DVCS options comme git et Mercurial sur SVN, TSF "check out" modèle semble un peu comme un dinosaure.

2) le Coût. Ceux qui disent que la TSF n'est pas cher sont certainement très petites boutiques, ou ne sont pas en conformité avec TFS de conditions de licence. Vous avez besoin d'une Licence d'Accès Client pour sacrément près tout ce que vous faites. Êtes-vous un gestionnaire qui parvient tout juste les bugs? Vous avez besoin d'un ~$250 CAL (Il y a 5 inclus avec un détail TFS Licence). Un utilisateur qui veut juste faire rapport sur leurs problèmes? UN MONTANT DE 250 $CAL. Un développeur? $250 (Sauf s'ils ont MSDN cas dans lequel il est inclus). Le serveur? De 500 $(Inclus si vous avez MSDN). Bien sûr, quelqu'un de vous vendre une copie de TFS vous dira que le suivi des éléments de travail est gratuit pour les utilisateurs supplémentaires, mais ces utilisateurs ne peuvent voir que les éléments de travail dont ils ont créer eux-mêmes, et non pas à l'ensemble de l'équipe, des éléments de travail, ce qui n'est pas trop utile dans un travail d'équipe, environnement agile. Tout cela s'ajoute, lorsque vous avez une organisation de taille moyenne, et devient difficile à justifier quand donc beaucoup de best-of-breed de produits comme SVN et CruiseControl.net'le coût incrémental est de 0$. (En toute équité, à la TSF, si, je suis toujours en attente d'une vraiment bonne OSS issue tracker)

3) la structure du Projet. Dans de grandes équipes avec un plus petit nombre de projets, TSF fonctionnera probablement. Si vous êtes un certain nombre de petits, déconnecté ou mal connecté à la ligne d'applications d'entreprise en interne, TSF de la structure peut commencer à devenir pesants. Pour une chose, il n'est pas possible de définir une taxonomie des projets eux-mêmes: vous pouvez définir des "Zones" au sein d'un projet, mais toutes les questions et les documents sont suivis conjointement dans le cadre d'un "projet". La création de nouveaux "projets" est souvent beaucoup de temps, et est overkill pour les petits efforts. Bien sûr, SVN a rien de la sorte, car il se concentre uniquement sur le contrôle de code source, mais si vous avez besoin d'un bon petit-projet de souplesse, SVN et une autre question outil de suivi pourrait être un meilleur choix.

Mon avis, pour ce que ça vaut:

• Pour les grandes équipes avec de grands, bien au budget des projets, dans un Microsoft boutique où les développeurs travaillent presque exclusivement dans l'IDE, TSF est le gagnant. TSF a également gagné quand vous avez la nécessité de centraliser les faire appliquer la politique de vos projets.

• Pour un certain nombre de petites équipes, avec de nombreuses et diverses, les plus petits projets, ou des magasins où le coût est un problème, la ou les équipes qui ont les développeurs qui travaillent déconnecté de la source de contrôle, aller avec SVN.

Answer 2

Je suis surpris que quelqu'un qui a utilisé la Subversion dans le passé, il aurait même une envie/besoin de TSF de contrôle de source.

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 bien structurer votre source pour les différents besoins de développement.

Notre situation simple, où nous avons un tronc avec de la canalisation principale le développement et l'intégration de la branche où nous intégrer les modifications et de les déployer à partir de, et une versions de la branche de garder une trace des dernières versions est très commun et facile, mais nous sommes en permanence en cours d'exécution dans les problèmes.

Mes principaux problèmes avec TFS:

• La fusion est une DOULEUR en comparaison à la subversion.
• Il y a des bugs corrigés. Je suis tombé sur un sujet de la modification/la fusion qui a été connu pendant 2 ans et qu'un correctif ne sera jamais publié en 2005. Nous avons terminé notre succursale à une "cassé" du dossier et nous l'ignorer maintenant.
• Mettre en lecture seule serrures sur vos fichiers de frottement. Qui a dit que j'ai besoin de modifier les fichiers de commandes et de scripts de compilation à l'intérieur de la TSF afin de "vérifier" pour moi? Subversion sait que les fichiers modifiés. Il n'y a pas readonly serrures.
• Vitesse. TFS est chien-lent sur un réseau WAN, et c'est vraiment utilisable que si je VPN sur mon ordinateur de travail, ce qui rend mon expérience de développement très lent dans l'ensemble.
• L'absence d'un bon de commande en ligne et d'explorer l'intégration. Intégration EDI est vraiment agréable pour la journée-à-jour-plus tard, l'ajout de fichiers, et de l'enregistrement, mais quand vous avez besoin de faire les choses à travers de nombreux projets, c'est agréable d'avoir de bons outils à votre disposition. Et avant que quelqu'un saute en bas de ma gorge prétendant tf.exe fonctionne bien... ce n'est pas vraiment une ligne de commande outil. Par exemple, la vérification dans le code ne devrait pas afficher une boîte de dialogue modale.

...la liste est longue. Je pense que même avec toute l'intégration, il y a des alternatives gratuites qui sont de loin supérieure.

Answer 3

J'ai rejoint un projet Open Source sur sur CodePlex, récemment. Ils utilisent TFS pour leur contrôle à la source et je dois dire que c'est absolument magnifique. Je suis très impressionné avec elle, jusqu'à présent. Je suis un grand fan de l'IDE de l'intégration et de la façon dont il est facile de la branche et de l'étiquette de votre code. L'ajout d'une solution à la source de contrôle est quelque chose comme deux clics, si vous avez déjà tout configuré correctement.

Maintenant. Est-il en valeur l'étiquette de prix élevé? Je ne le pense pas. L'avantage de travailler sur des projets à CodePlex est qu'il me permet d'acquérir de l'expérience avec TFS que j'ai besoin, dans le cas que j'ai à l'utiliser quelque part plus tard. Si vous voulez une bonne intégration EDI pour votre Contrôle de code Source, aller prendre VisualSVN package d'intégration. C'est beaucoup, beaucoup moins cher à l'investissement pour obtenir un grand nombre des mêmes caractéristiques (gratuit sur la non-ordinateurs du domaine BTW).

Answer 4

Nous sommes un VS.NET boutique, et nous avons mis en œuvre:

1. Bugzilla pour le suivi des problèmes
2. Apache Subversion comme un référentiel de code source back-end
3. VisualSVN Serveur pour la gestion de SVN sur le serveur
4. TortoiseSVN (dans l'Explorateur Windows) et AhnkSVN ou VisualSVN (dans Visual Studio) sur le client
5. CruiseControl.NET pour les générations automatisées

Prix: $0 Avantages: Priceless

Si vous êtes une petite équipe, ou ne sont pas prêts à acheter dans le qui TFS processus, SVN et les outils open source sont le chemin à parcourir.

Answer 5

Comme d'autres l'ont souligné, TSF vous donne beaucoup plus de fonctionnalités, puis SVN n'est dans la forme de la gestion de projet et. Ayant utilisé les deux, et a travaillé avec de très grandes entreprises dans la mise en œuvre de TSF, voici mes deux cents.

1) Si vous utilisez TFS 2005, la mise à niveau vers TFS 2008. Vous allez me remercier. Il y a une tonne d'améliorations dans TFS 2008 que la rendre efficace.

2) Si vous vivez dans Visual Studio et que vous souhaitez l'intégration EDI, aller avec TFS. J'ai utilisé SVN intégration et presque toujours tomber en arrière à l'aide de TortoiseSVN.

3) Si vous aimez l'idée de comptes intégrés de l'Authentification Windows, aller avec TFS. La gestion de cette fin, c'est agréable. Il y a peut être des crochets pour SVN - je ne suis pas positif, mais si vous aimez l'interface graphique de gestion basée sur le, TSF est dur à battre.

4) Si vous avez besoin de suivre les mesures ou ont des moyens plus faciles de mise en œuvre de choses comme les stratégies d'archivage aller avec TFS.

5) Si vous avez des gens qui ne veulent pas le mettre en œuvre si elle n'est pas MSFT, aller avec TFS.

6) Si vous faites plus que juste .NET (Java travail, Eclipse,...) aller avec SVN. Oui il y a de très bons produits là-bas (comme Teamprise) qui fonctionnent bien avec TFS. Mais à moins que les autres langues sont une petite partie de votre boutique, il suffit de coller avec SVN.

En dehors de cela, la SCM fonctions de deux sont à peu près équivalent. Ils ont tous deux faire le branchement et la fusion, les deux ne atomique check-ins, ils ont à la fois le soutien renomme et déplace. Je pense que pour les personnes qui débutent avec le branchement et la fusion de concept, ayant les branches visible dans l'Explorateur du Contrôle de Source est agréable.

TFS n'est vraiment pas cher ($1200 peut-être?). Par rapport à SVN c'est, peut-être. L'intégration de reporting services SharePoint est sympa, mais encore une fois, si vous ne l'utilisez pas, alors il n'a pas d'importance.

Ce que je dirais, c'est de télécharger l'essai de 180 jours de TSF et de lui donner un aller. Exécuter un essai side-by-side. Je pense que vous allez être heureux, peu importe la façon dont vous allez.