SVN vs. Team Foundation Server [fermé]

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

1) TFS est plutôt étroitement couplée à de la "Visual Studio manière" de faire du développement. ce n'est pas pour dire que TFS est étroitement couplé à L'IDE VS, cela signifie que TFS lutte pour garder le familier"check in"/" check out " paradigme de Visual SourceSafe, même si ce n'est vraiment pas un modèle approprié plus. Le concept de "commit"/"update" de Subversion est énorme plus réaliste lorsque vous avez des développeurs qui pourraient passer du temps déconnecté du réseau. TFS s'attend à ce que les développeurs soient toujours connectés au serveur. C'est un gros moins. Personnellement, je trouve que TFS est moins que 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 Visual Studio. Même les plus grands promoteurs de TFS concèdent que son modèle de check-in/check-out connecté n'est pas une option convaincante pour les développeurs qui travaillent déconnectés. Dans un climat où les gens commencent à regarder les options DVCS comme Git et Mercurial sur SVN, le modèle "check out" 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 sont pas en conformité avec les conditions de licence de TFS. Vous avez besoin d'une licence Client Access pour presque tout ce que vous faites. Êtes-vous un manager qui gère juste les insectes? Vous avez besoin d'un ~$250 CAL (Il ya 5 inclus avec une licence TFS de détail). Un utilisateur qui veut juste faire rapport sur leurs problèmes? UN CAL À 250$. Un développeur? 250 $(à moins qu'ils N'aient le MSDN, auquel cas il est inclus). Le serveur? $ 500 (inclus si vous avez MSDN). Bien sûr, quelqu'un qui vous vendra 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 pas les éléments de travail de toute l'équipe, ce qui n'est pas trop utile dans une équipe orientée, environnement agile. Tout cela s'additionne quand vous avez une organisation de taille moyenne, et devient difficile à justifier quand tant de produits meilleurs de la race comme SVN et CruiseControl.net le coût différentiel est de 0$. (En toute justice pour TFS, cependant, je suis toujours en attente d'un vraiment bon tracker de question OSS)

3) structure du projet. dans les grandes équipes avec un plus petit nombre de projets, TFS fonctionnera probablement bien. Si vous êtes un nombre de petits, applications de ligne d'affaires non connectées ou vaguement connectées en interne, la structure de TFS peut commencer à devenir prépondérante. D'une part, il n'est pas possible de définir une taxinomie des projets eux-mêmes-vous pouvez établir des "zones" au sein d'un projet, mais toutes les questions et tous les documents sont suivis ensemble dans le contexte de base d'un "projet". La création de nouveaux "projets" prend souvent beaucoup de temps et exige trop de petits efforts. Bien sûr, SVN n'a rien de tel car 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 opinion, pour ce que ça vaut:

• pour les grandes équipes avec de grands projets bien budgétisés, dans une boutique Microsoft où les développeurs travaillent presque exclusivement au sein de L'IDE, TFS est le gagnant. TFS gagne aussi quand vous avez besoin de centraliser l'application de la politique avec vos projets.

• pour un certain nombre de petites équipes, avec de nombreux projets variés et plus petits, ou des magasins où le coût est un problème, ou des équipes qui ont des développeurs qui travaillent déconnectés du contrôle source, aller avec SVN.

je suis surpris que quelqu'un qui a utilisé Subversion dans le passé ait même besoin du contrôle des sources de 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 bien structurer votre source pour divers besoins de développement.

notre situation simple, où nous avons un tronc avec le développement de la ligne principale, et la branche d'intégration où nous intégrons des changements et déployons à partir, et une branche de publication pour suivre les publications passées est très courante et simple, mais nous sommes constamment confrontés à des problèmes.

mes principaux problèmes avec TFS:

• la fusion est une douleur par rapport à la subversion.
• il y a des bugs non fixés. Je suis tombé sur un sujet de renommer / fusionner qui est connu depuis 2 ans et un correctif ne sera jamais publié pour 2005. Nous avons fini par déplacer notre branche dans un dossier" cassé " et nous l'ignorer maintenant.
• mettre des serrures en lecture seule sur vos fichiers est une friction. Qui dit que je dois éditer des fichiers par lots et construire des scripts à l'intérieur de TFS pour qu'il "vérifie" pour moi? Subversion sait quels fichiers ont été modifiés. Il n'y a pas readonly serrures.
• de la Vitesse. TFS est dog-slow sur un WAN, et il n'est vraiment utilisable que si je VPN dans mon ordinateur de travail, ce qui rend mon expérience dev vraiment lent dans l'ensemble.
• manque de bonne intégration de la ligne de commande et de l'Explorateur. L'intégration D'IDE est vraiment agréable pour le quotidien Obtenir-Dernier - né, ajouter des fichiers, et vérifier, mais quand vous avez besoin de faire des choses à travers 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 réclamant tf.l'exe fonctionne bien... ce n'est pas vraiment une ligne de commande outil. Par exemple, la vérification du code ne devrait pas faire apparaître de dialogue modal.

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

nous sommes VS.NET

1. Bugzilla pour le suivi des problèmes
2. Apache Subversion comme référentiel de code source back-end
3. VisualSVN Serveur pour la gestion de SVN sur le serveur
4. TortoiseSVN (dans Windows Explorer) et AhnkSVN ou VisualSVN (en studio visuel) sur le client
5. CruiseControl.NET pour constructions automatisées

coût: 0 $ Avantages: Inestimable

si vous êtes une petite équipe, ou si vous n'êtes pas prêt à participer au processus OMS TFS, les outils SVN et open source sont la solution.

comme d'autres l'ont souligné, TFS vous offre beaucoup plus de fonctionnalités que SVN ne le fait sous forme de gestion de projet et autres. 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, passez à TFS 2008. Vous allez me remercier. Il y a une tonne d'améliorations dans TFS 2008 qui le rendent réalisable.

2) Si vous vivez dans Visual Studio et que vous voulez l'intégration IDE, allez avec TFS. J'ai utilisé L'intégration SVN et je reviens presque toujours à L'utilisation de TortoiseSVN.

3) Si vous aimez l'idée de comptes intégrés avec L'authentification Windows, allez avec TFS. La maniabilité de ce côté est agréable. Il peut y avoir des crochets pour SVN - Je ne suis pas sûr, mais si vous aimez la gestion GUI driven, TFS est difficile à battre.

4) Si vous avez besoin de suivre les paramètres ou d'avoir des moyens plus faciles de mettre en œuvre des choses comme les politiques d'enregistrement, allez avec TFS.

5) Si vous avez des gens qui ne veulent pas l'implémenter si ce N'est pas MSFT, allez avec TFS.

6) Si vous faites plus que simplement .NET (Java work, Eclipse, etc) allez avec SVN. Oui, Il ya de très bons produits là-bas (comme Teamprise) qui fonctionnent bien avec TFS. Mais à moins que les autres langues ne soient une petite partie de votre boutique, il suffit de s'en tenir à SVN.

en dehors de cela, les caractéristiques SCM des deux sont à peu près équivalentes. Ils se ramifient et fusionnent, les deux font des check-in atomiques, ils supportent les renommages et les mouvements. Je pense que pour les gens qui viennent de commencer avec le concept de branchement et de fusion, avoir les branches visibles dans L'Explorateur de contrôle Source est agréable.

TFS n'est vraiment pas si cher (1200$peut-être?). Par rapport à SVN, peut-être. L'intégration aux services de rapports et SharePoint est agréable, mais encore une fois, si vous n'utilisez pas cela, alors cela n'a pas d'importance.

ce que je dirais c'est téléchargez l'essai de 180 jours de TFS et donnez-lui une chance. Exécuter un essai side-by-side. Je pense que tu seras heureux peu importe où tu iras.

comme Ubiguchi le souligne TFS n'est pas un produit de contrôle de version. Acheter TFS avec l'intention de l'utiliser seulement 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 axée sur "L'entreprise".

également per Ben s post - Je ne comprends pas votre commentaire sur les serrures. Les serrures ne sont pas nécessaires dans le TFS. Les administrateurs peuvent configurer TFS pour qu'il fonctionne comme VSS (fonctionnalités exigées par certains clients "imprudents") pour "obtenir-Dernière sur la caisse" qui, je crois fait aussi un check-out lock.

mais grâce à L'utilisation" normale "de TFS un" check-out "invite un utilisateur pour le type de serrure - et la valeur par défaut devrait être"none". Un utilisateur PEUT sélectionner un check-out (ou un check-in lock) - mais il n'est pas nécessaire. Si vous ne voulez pas de serrures, ne les utilisez pas.

TFS ne piste quels utilisateurs ont des checks-outs sur le serveur pour divers à la fois raisons de performance (make get-le plus récent plus rapide) et la gestion de projet (j'aime voir ce que les développeurs ont vérifié les fichiers et la durée de leurs vérifications sont).

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 touché le bogue de fusion Ben s rapporté - mais j'ai eu un grand succès avec brancher et fusionner en utilisant TFS.

Un cas d'utilisation je sais TFS est encore assez faible à l'est pour les utilisateurs qui sont régulièrement "hors ligne". TFS est un" produit serveur " qui suppose que les utilisateurs sont connectés la plupart du temps. L'expérience hors ligne s'est améliorée dans la version 2008 (il a été lugubre en 2005), mais a encore un long chemin à parcourir. Si vous avez des développeurs qui ont besoin (ou qui veulent) d'être souvent déconnectés du réseau pendant de longues périodes - Vous êtes probablement mieux lotis avec SVN.

une autre caractéristique à considérer pour les fans de SVN qui utilisent TFS est le Pont SVN un codeplex qui permet aux utilisateurs D'utiliser TortiseSVN pour se connecter à TFS. Je suis un bon ami et un collègue qui l'utilise abondamment et qui l'aime.

aussi le commentaire sur le manque de ligne de commande me surprend - les outils en ligne de commande sont vastes (bien que beaucoup exigent un téléchargement séparé de TFS Power Tools

je soupçonne les commentaires de Ben sont basés sur une évaluation de la version 2005 qui était clairement un" Microsoft V1.0 0" produit. Le produit est actuellement en 2.1 avec la Version 3 à venir dans un proche avenir.

TFS est odieux. À ce stade, je contrôle la version localement en utilisant SVN (W/ Live Mesh pour les sauvegardes) parce que j'ai de nombreux problèmes avec TFS. Le problème principal est que TFS utilise des horodateurs pour enregistrer si vous avez la dernière version, et stocke ces horodateurs sur le serveur. Vous pouvez supprimer votre copie locale, Obtenir la dernière de TFS, et il dira tous les fichiers sont à jour. C'est un système stupide qui ne vous donne aucune garantie que vous avez la version correcte des fichiers. Il en résulte de nombreuses nuisances:

• TSF doit être informé lorsqu'un fichier est modifié, donc vous devez être connecté au serveur à tout moment.
• TFS est confus si vous éditez des fichiers en dehors de L'IDE. En outre, il définit tous les fichiers à lire uniquement dans NTFS.

alors que TFS supporte la fusion, c'est en fait un système de vérification. Si vous modifiez un fichier, vous trouverez souvent qu'il est verrouillé à d'autres développeurs. Il y a des façons de contourner c', mais le système est tellement alambiqué, vous courez toujours le problème. Par exemple, nos développeurs ont trouvé qu'ils peuvent contourner tous les fichiers étant définis en lecture seule dans NTFS en vérifiant une solution complète, qui définit une serrure exclusive sur tous les fichiers. J'ai fait cela plusieurs fois parce que subversion a la même syntaxe pour checkout, qui n'acquiert pas de verrouillage.

enfin L'Explorateur D'équipe (le client) est un 400 MB fracassant, le serveur de TFS nécessite SharePoint et deux jours pour installer. L'installateur subversion one click est d'environ 30 Mo et installera le serveur pour vous en moins d'une minute. TFS a de nombreuses fonctionnalités, mais sa fondation est si fragile que vous ne les utiliserez jamais ou ne vous en soucierez jamais. TFS est cher en termes de licence, et dans le temps les développeurs vont gaspiller rooting sur stackoverflow au lieu d'écrire le code :p

ma recommandation, le système D'équipe ne vaut pas l'argent. J'ai utilisé les deux et après avoir utilisé le système Team, j'ai essayé de trouver un remplacement similaire. Fondamentalement, ce que vous payez est l'intégration et vous pourriez argumenter le soutien de personnalisation, mais j'ai été en mesure de créer un système de remplacement D'équipe avec un peu de temps et l'intégration des outils ensemble.

j'ai récemment poser une question sur ce que les autres ont fait de venir avec une Équipe Système de remplacement. J'énumère é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 trouverez ce qui fonctionne pour vous.

Je ne déteste pas le système D'Équipe, Je ne pense pas que ça en vaille la peine. C'est un très bel outil et si cela ne vous dérange pas de payer le prix, alors par tous les moyens l'utiliser. C'est la raison pour laquelle j'ai créé le remplacement que j'ai trouvé. Je voulais que le système d'équipe de fonctionnalité soit fourni.

Voici une version open source de VisualSVN appelée Ankhsvn . Son beaucoup mieux maintenant que collabnet a repris.

si vous n'avez besoin que d'un contrôle à la source, TFS est surmené. Un de mes anciens employeurs avait TFS, VSS et Subversion dans son entreprise. Nous n'avions pas Active Directory ou Exchange Server 2003 dans notre entreprise, donc nous avons fini par créer des utilisateurs séparés sur le serveur TFS pour que les développeurs puissent l'utiliser. Nous avons eu le même genre de problèmes avec la fusion que Ben Schierman a mentionné, ainsi que d'autres comportements buggés qui nous ont poussés vers Subversion.

si TFS est le le bon appel pour vous dépendra en partie de votre budget, de la taille de votre équipe de développement, et du temps et du personnel disponibles pour la configuration/maintenance de votre solution. Si vous voulez les capacités supplémentaires de suivi des problèmes, des travaux et des statistiques de projet que TFS fournit, il peut être utile d'examiner d'autres alternatives. Des produits comme JIRA (de Atlassian Systems) ou Trac s'intègrent bien à Subversion et fournissent le type de supervision d'un projet ou d'un programme le directeur pourrait à un prix plus bas.

dans un environnement idéal, avec Active Directory, Exchange Server 2003 ou plus, et du personnel dédié pour le dépôt, TFS est plus susceptible d'être un bon choix.

j'ai utilisé à la fois au travail et à la maison. Ils sont tous les deux très cool à part entière. La seule fois où je recommande L'utilisation de TFS est cependant si vous allez utiliser plus de fonctionnalités que juste le contrôle source. Si tout ce dont vous avez besoin est le contrôle source, vous ne pouvez pas vous tromper avec SVN et c'est pourquoi.

1. VisualSVN Server qui est un serveur SVN complet avec un beau plugin pour le gérer. Il vous permet d'utiliser l'authentification windows droit par le biais de l'INTERFACE utilisateur. Facile.

2. Tortue sa tortue, assez dit.

3. ankhsvn c'est un grand plugin SCC. Pour ceux qui veulent une intégration complète VS IDE, la dernière version est un plugin SCC complet. Donc vous obtenez maintenant l'intégration complète gratuitement.

L'ensemble ci-dessus est 100% gratuit et vous obtiendrez par tout ce dont vous avez besoin pour le contrôle des sources.

TFS n'est pas qu'une question de contrôle à la Source. Si vous utilisez L'ensemble du paquet proposé par TFS, suivi de bogues, compilations, rapports, etc., alors TFS est un choix assez solide (certainement meilleur que rationnel). TFS s'intègre aussi bien avec Active Directory.

bien que si vous parlez simplement de SCM, alors je préfère SubVersion. Je n'aime pas vraiment intégration EDI. J'aime aussi la convention de SVN sur la structure du tronc/Tags/Branches, et la facilité relative de passer d'une branche à l'autre. La fusion semblait plus facile dans TFS. L'UI de Tortoise bat les mains de TFS, surtout en ce qui concerne l'ajout d'un fichier à une pension.

je dirais que ça dépend vraiment de vos besoins. TFS est très agréable, je l'ai beaucoup utilisé, mais il est très ciblé au niveau de l'entreprise, si vous n'avez pas besoin de toutes ces fonctionnalités, il pourrait ne pas être nécessaire. Si vous avez besoin de ces fonctionnalités (notamment branchement, évolutivité, suivi des travaux, etc.)), ils sont vaut chaque centime. Gardez à l'esprit que TFS inclut le suivi des bogues, le suivi des éléments de travail et d'autres fonctionnalités hors contrôle des sources. Si vous avez plusieurs branches ou si vous vous trouvez lutter contre un manque de fonctionnalité ou autre dans Subversion pourrait être une bonne idée de basculer. Mais à moins d'avoir une bonne raison de changer de source, vous devriez probablement éviter le coût et la productivité liés à la commutation des systèmes de contrôle des sources.

ayant largement utilisé les deux, je pense que Wedge était sur l'argent en notant "TFS comprend le suivi des bogues, le suivi des travaux et d'autres fonctionnalités hors contrôle des sources".

cependant, je peux honnêtement dire que SVN et TFS semblent assez égaux en ce qui concerne l'évolutivité, et si quelque chose SVN contrôle des sources a l'avantage sur TFS en raison de sa simplicité inhérente.

si vous voulez un suivi des tâches et des bogues à côté de votre contrôle source, alors vous pouvez soit aller pour TFS ou vous allez avec SVN et d'autres outils, éventuellement gratuits, comme bugzilla. Alors que TFS intègre à la fois le contrôle des sources et le suivi des éléments de travail, je pense honnêtement que MS aurait dû le donner gratuitement comme excuse pour avoir abusé de tant de développeurs avec VSS au fil des ans.

j'ai utilisé SVN et TFS. Le principal avantage de L'utilisation de TFS est son intégration étroite avec Visual Studio. Le suivi des bogues, le suivi des tâches se fera en un seul endroit. De plus, les rapports produits pour ces éléments aideront les intervenants à se tenir au courant de l'état d'avancement du projet.

je travaille sur un projet avec 5 personnes et nous sommes récemment passés de SVN à TFS. Tout le processus a été un cauchemar. Nous avons le 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 scanner votre caisse et corriger ce problème, mais c'est une douleur 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 utilisé. On aurait penser que TFS serait en mesure de gérer les fusions solution 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 a aussi des défauts. Si je checkout de mon explorateur de solutions, parfois les fichiers qui ont été ajoutés ne sont pas vérifiés. Si je le fais depuis la fenêtre de contrôle des sources de L'équipe, ça marche parfaitement. Pourquoi est-ce? J'ai hâte de voir TFS dans VS2010 car j'ai entendu de grandes choses à ce sujet, et SVN est loin d'être parfait, mais j'aurais on s'attendait à ce que certaines de ces fonctionnalités fonctionnent un peu plus intuitivement.

Adam

TFS est excellent pour la gestion et le suivi de projets, mais je pense que le contrôle source n'est pas aussi bon que SVN. Voici mes beefs avec TFS:

Check-in/Check-out model

c'est une énorme arnaque pour le contrôle à la source de TFS. Malheureusement, VS vérifie automatiquement les éléments pour vous, même si vous ne voulez pas. J'ai été dans une situation où quelqu'un a vérifié des dossiers et est parti en vacances. J'ai été en charge de la restructuration de la structure du répertoire, mais n'a pas pu parce qu'un tas de fichiers ont été vérifiés à cette personne. Il n'y a aucun moyen dans le GUI de défaire la caisse, ce qui signifie qu'il a dû être fait un par un dans la ligne de commande. Ou je devais trouver comment écrire un script d'interpréteur de commandes pour ça.

VS est nécessaire à tout faire

Parfois, je veux éditer un fichier texte et l'enregistrer. Cela me demande de démarrer VS 2010, ce qui est une énorme bête, juste pour modifier un fichier et l'enregistrer. Quelque chose qui a pris quelques secondes avec SVN me prend maintenant une minute.

comme d'autres l'ont fait remarquer, les fichiers sont marqués en lecture seulement s'ils ne sont pas vérifiés. Si vous le rendez accessible en écriture et l'Éditez en dehors de VS, TFS ne le reconnaîtra pas. Cela rend l'édition de quelque chose en dehors de VS ennuyeux. Cela signifie, allumer VS, vérifier le fichier, l'éditer un autre éditeur, vérifier dans VS.

"certaines opérations qui étaient faciles dans SVN sont maintenant une douleur

• peut-être que je ne l'ai pas encore compris, mais j'ai trouvé que revenir en arrière un ensemble de changements était très fastidieux avec TFS.

• ajouter des fichiers au contrôle source, qui ne font pas partie d'une solution, est une énorme douleur. L'Explorateur de contrôle source de TFS ne montre que les fichiers qui sont dans le contrôle source, pas ceux qui ne le sont pas (peut-être qu'il y a un paramètre quelque part, je ne sais pas). Avec Tortoise SVN, je pourrais simplement appuyer sur Commit sur un dossier et sélectionner les fichiers à ajouter.

je dirige actuellement l'effort pour évaluer TFS à mon entreprise par rapport à la suite rationnelle qui est ce que nous utilisons actuellement. Jusqu'à présent TFS 2008 est pwning clearcase + clearquest. L'intégration de l'environnement dev est là où elle brille vraiment.

mes 10 cents:

TFS2005 était une blague - difficile à installer et encore plus difficile à maintenir TFS2008 était stable - plus facile à installer, entretien plus simple, et les constructions automatisées qui fonctionnent. TFS2010 est épique! - installation est chien eassssyyy. La gestion est très facile; C'est une interface utilisateur très bien conçue. L'intégrer avec VS2008 n'est pas si facile puisque vous ne pouvez pas créer des projets dans vs2008 vous devez utiliser vs2010 (qui est stupide). TFS2010 vous permet également de changer le sharepoint l'emplacement du projet au lieu d'avoir ces horribles sous-dossiers de TFS2008. TFS2010 dispose également d'outils tels qu'un tableau d'épuisement qui est vraiment utile pour la gestion de projet. C'est comme TFS2010 pour toute l'équipe de production, y compris les clients! Il coûte encore beaucoup trop cependant :(

tient également compte du fait que TFS nécessite beaucoup plus de chevaux-vapeur provenant du matériel du serveur. Et au moins une licence Windows server ofcourse.

meilleure pratique, comme notre société a suivi, est d'utiliser deux serveurs: front-end (avec sharepoint intégré), et un serveur sql dédié dans le back-end (nous utilisons un cluster d'entreprise). TFS peut être installé sur 1 machine, mais ne devrait pas.

en comparaison, notre serveur svn est installé sur un linux virtuel serveur avec 256Mo de ram et 1 cpu, et est encore plusieurs magnitudes plus rapide lorsque vous faites des tâches communes comme checkout-all. Le matériel virtuel était le plus bas que vshpere pouvait assigner! Le disque est rapide cependant (SAN).

je suggère que TFS nécessite du matériel dédié pour au moins $5000, tandis que svn server (sous linux) peut fonctionner avec n'importe quel matériel obsolète pour les systèmes d'exploitation windows actuels.

À mon avis, cela dépend de la situation et de l'environnement dans lequel le projet est réalisé. Si vous avez juste un simple, petit projet, alors SVN est grand. Comme certains l'ont déjà écrit, VisualSVN s'intègre bien dans Visual Studios.T. vous n'avez pas besoin de faire le checkin/checkout sur le système de fichiers natif.

TFS est idéal pour le contrôle de version, mais encore mieux si vous utilisez vraiment toutes ses capacités. À mes yeux, cela vaut vraiment la peine si vous utilisez - par exemple - work items comme votre référentiel intégré pour le traitement des rapports de bogue des clients, des demandes de nouvelles fonctionnalités et pour le suivi de l'avancement de votre projet en gérant les tâches et l'heure estimée, le temps utilisé et les indications de temps restant.

Ce qui est également vraiment intéressant est d'utiliser la fonctionnalité d'associer des éléments de travail avec des checkins de code source. Voir ici pour plus d'informations à ce sujet.

nous sommes une petite équipe dans le processus de migration de SVN à TFS2010. Notre plus grande raison de le faire est l'intégration dans Visual Studio et le WebAccess pour le bugtracking, qui fait maintenant partie du TFS.

@Adam: espérons que nous aurons une meilleure expérience. Ne peut pas le dire pour l'instant...

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 encombrant que SVN et à l'exception de la bonne intégration avec les tâches/bogues, Je ne le vois pas comme ayant un avantage par rapport à SVN. La vitesse semble également être un peu plus lente qu'avec SVN.

si je devais choisir un sourcecontrol maintenant, J'irais toujours avec SVN.

concernant les outils: - AnkhSVN Visual Studio Plugin is aussi bon que le contrôle source de TFS - La tortue est bien meilleure que la contrepartie TFS

TFS est grande, si vous n'avez pas besoin des non-développeurs, pour obtenir des particules de trucs.

notre service d'assistance doit être impliqué dans le processus, et ça n'a pas marché.

aussi la gestion de construction dans tfs 2005 au moins, est attr otitive, et il ne peut même pas construire vs 2008 slns. Je n'aime vraiment pas que mon choix de source de contrôle, affecte mes choix de déploiement, c'est pourquoi mon équipe n'est pas un magasin svn.

si c'était juste basé sur le contrôle source, J'utiliserais SVN. L'ajout gratuit D'AnkhSVN pour Visual Studio a été grandement amélioré dans sa nouvelle version. En outre, vous obtenez le code source pour SVN et la documentation est grande! Ils ont changé certaines choses arcanes dans le contrôle Source de TFS 2010, et sans le code source, il peut être très intimidant de dépanner. De plus, vous dépendez de L'équipe MSDN pour pomper les docteurs et eux le font selon leur propre horaire et à leur propre profondeur.

cela dit, TFS, évidemment, offre beaucoup plus de contrôle à la source . C'est un ALM outil. Combinaison avec des éléments de travail, des rapports, des constructions automatisées, check-in fermé , des 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 la source car SVN n'est pas une sécurité. J'ai étudié des scénarios avec SVN où il aurait fallu des semaines pour comprendre ce qui se passait.

donc, je vous recommande de le regarder d'un point de vue ALM et voir si votre entreprise va utiliser toutes les caractéristiques TFS ou va avec une stratégie de Meilleur-of-breed (par exemple JIRA).

TFS d'un mile.

par inadvertance, je me crée trop de problèmes avec L'approche basée sur les fichiers SVNs. Problèmes de contrôle des sources: TFS-0 problèmes sur 2 ans SVN – perdu le compte...

Oui je sais que le prix de TFS facteurs it out pour la plupart des entreprises qui est une telle honte. Les États membres pourraient avoir beaucoup plus de parts de marché (et de bénéfices) s'ils avaient un modèle de tarification raisonnable.