TFS vs SVN [fermé]

on ne peut pas comparer entre TFS et SVN "

SVN : système de gestion de versions de code Source

TFS : système de gestion de développement logiciel complet qui contient, le contrôle de Version, la gestion de publication, le suivi des exigences, la publication de documents et d'autres choses.

les deux ont agréable à utiliser L'intégration IDE add-ins (par ex. AnkhSVN, Add-in de Collabnet) disponible pour VS2005, de sorte que ce n'est pas le point à considérer.

critères à prendre en considération pour le choix :

- Si vous avez un projet non ou petit budget choisir SVN

- Si vous cherchez uniquement le système de contrôle de version, choisissez SVN , si vous cherchez la gestion complète du développement, choisissez TFS

- Si vous avez la patience de jongler avec différents outils d'intégration (CruiseControl.Net, NUnit, NCover, FIT) pour réaliser l'environnement de développement approprié choisir SVN , ou si vous recherchez hors de la mise en œuvre de tous ceux-ci pour vous choisissez alors TFS

ayant utilisé TFS il y a 18 mois, je l'ai trouvé buggy, lent, ennuyeux, critères de recherche très limités et il avait l'impression d'un produit précipité par une équipe de non-intéressés, sous-payés, sur techs travaillé étant forcé d'utiliser Sharepoint et D'autres technologies de MS parce que c'est ce que le marketing voulait. Sérieusement c'était un chien, j'aurais préféré utiliser SourceSafe!

SVN d'un autre côté est un peu technique, intégration IDE est une douleur, et il peut parfois être confus, mais la base d'utilisateurs est énorme et la plupart des problèmes peuvent être résolus avec une question rapide.

avez-vous considéré voûte ? Fonctionne bien, et ce n'est pas trop cher.

Je ne recommande TFS que si vous utilisez la version 2013 et le référentiel basé sur Git. J'ai rencontré trop de problèmes avec les versions précédentes de les considérer stable.

• il est impossible d'envoyer plusieurs fichiers à votre outil diff à la fois. C'est ridiculement utile quand vous voulez revoir vos modifications avant une fusion et n'est pas disponible.
• manque de fonctionnalité. Certaines fonctionnalités sont disponible uniquement à l'intérieur de L'IDE alors que D'autres pièces ne sont disponibles qu'à partir de Windows Explorer, tandis que d'autres encore ne sont disponibles qu'à partir de la ligne de commande.
• ajouter des fichiers au contrôle de version n'est pas disponible à partir de L'IDE et n'est disponible qu'à partir de Windows Explorer integration.
• L'accès à des ensembles d'étalage est seulement disponible à partir de l'IDE et non disponible par L'intégration de Windows Explorer.
• absence d'une seule unité installateur. Il ne suffit pas d'installer TFS, il faut aussi installer des outils d'équipe et des outils électriques pour obtenir des fonctionnalités de base.
La fonctionnalité
• ne fusionne pas. Ce qui aurait pu être une façon cool de faire les succursales privées, garantit essentiellement votre code va sortir de la date et arrêter de travailler.
• vous devez déverrouiller manuellement les fichiers texte avant de les éditer si vous avez besoin d'utiliser un éditeur autre que Visual Studio.
• Parfois Visual Studio oublie de débloquer les fichiers qu'il gère lui-même et envoie une erreur.
• l'enregistrement et la mise en mémoire des fichiers de base UIs disponibles pour commit sur ce qui a déjà été ajouté à TFS et non sur ce qui est réellement présent dans le système de fichiers. Cela rend extrêmement facile de manquer des fichiers. (C'est en fait un problème avec la façon dont Visual Studio gère les fichiers de projet, mais c'est en soi une autre ironie).
• il est inutilement difficile de utilisez des outils non Microsoft pour éditer votre source en raison des problèmes mentionnés précédemment.
La configuration
• TFS est engagée avec votre source. Cela signifie que si vous changez votre serveur TFS, la configuration pour toute votre histoire est maintenant incorrecte. Il y a une configuration par défaut que vous pouvez utiliser qui l'emporte sur ce comportement mais ce n'est pas évident.
• pas de support pour ignorer les filtres sauf au niveau de base.
• incapacité à manipuler les chemins de plus de 249 caractères.
• les Fichiers qui ont été débloqués, mais pas modifié afficher comme changement, même s'ils ne l'ont pas été. Faire la différence entre le déverrouillage et le déverrouillage rendrait la tâche beaucoup plus facile pour les diffs, ou mieux encore, éliminer entièrement le système de déverrouillage défectueux.
L'icône
• de L'Explorateur de Windows n'indique pas clairement si un fichier a été modifié. Tous les fichiers de TFS ont un coin vert tandis que les fichiers modifiés ajoutent un crayon au bas de l'icône. Passer au coin rouge pour modifié serait beaucoup plus facile à voir ou en utilisant le système d'icônes de la tortue.
• les anciennes versions de Visual Studio ont des problèmes d'intégration dans les nouvelles versions de TFS. Cela signifie que nous avons maintenant une dépendance de version IDE dans le contrôle source.
• inclut les fichiers de la solution utilisateur par défaut quand ils ne sont pas nécessaires. Bien sûr, j'admets que celui-ci pourrait être une question de préférence.
• une mauvaise mise en cache rend possible que les différences entre votre copie locale et le serveur ne soient pas reflétées correctement. Il est extrêmement frustrant D'obtenir la dernière et de constater que vous n'avez pas réellement dernière.

cela fait un an et demi que J'utilise SVN pour divers projets. Les configurations que j'ai utilisées jusqu'à présent:

• AnkhSVN client pour Visual Studio. Il s'intègre bien en tant que fournisseur de contrôle Source depuis la version 2.
• Serveurs CollabNet Subversion sur windows ou Apache 2.2 avec SSL + SVN par DAV sur linux.

N'ont eu aucun problème avec l'un des ces configurations et moi recommandons d'utiliser SVN car C'est gratuit et facile à utiliser. En outre, de nombreux paquets de gestion de projet / suivi des bogues s'intègrent avec SVN (comme trac par exemple).

je choisirais SVN. J'ai déjà travaillé avec SVN du point de vue des développeurs et je travaille actuellement avec TFS, et permettez-moi de vous dire que TFS est douloureux. Alors que TFS est doté de toutes les fonctionnalités et est plus qu'un simple contrôle de version, son contrôle de version est au mieux bâclé. La fusion est épouvantable et beaucoup d'entre nous se tournent maintenant vers des outils de fusion manuelle ou de fusion parce que nous ne pouvons pas compter sur TFS. Les fichiers sont portés disparus, ne sont pas téléchargés sur le système local parfois, et il ya juste des bizarreries dans son comportement qui vous voulez taper la tête contre un bureau.

cela étant dit, si vous voulez TFS dans toute sa gloire, sont prêts à travailler avec ses points de douleur, il est un grand outil pour mettre en place des constructions automatisées, et des versions.

j'ai utilisé les deux - mais en fait, j'ai changé mes principaux projets de TFS en SVN. Je trouve l'accès en ligne et anonyme très précieux dans mes projets.

En général, je pense qu'ils sont comparables. Je choisirais celui que tu connais le mieux, et tu es le plus heureux. Je ne trouve pas que les caractéristiques spécifiques d'un système soient plus importantes que celles de l'autre.

consultez cet article avant de vous décider: une comparaison de TFS vs Subversion pour les projets Open Source

si vous connaissez svn, Je m'y tiendrais. Tsf n'est pas libre et n'est pas simple. Cela fait bien plus que le contrôle à la source. Si vous êtes un .net shop comme nous et que vous décidez quel produit à utiliser pour l'ensemble du cycle de développement, il est un concurrent, mais pour le contrôle des sources simples, il est exagéré.

je dirais que TFS est plus qu'un simple contrôle à la source. Si vous pouvez vous le permettre, je n'hésiterais pas à conseiller à l'utiliser. Lorsque vous commencez à utiliser Team Builds par exemple, ou des choses comme des éléments de travail, alors vous verrez que TFS peut vraiment gérer l'ensemble de votre cycle de développement, fournissant un environnement riche dans lequel les rapports, la facilité d'utilisation, l'intégration slick VS et le contrôle des sources solides sont tous roulés en un seul.

il faut un peu de fer du côté du serveur. Je ne le trouve pas pour être lent cependant, il fonctionne bien sur VPN et soutient le travail hors ligne.

un inconvénient majeur est le processus d'installation (côté serveur) qui est fastidieux, non flexible et dans mon esprit (je viens d'un domaine dans lequel l'empaquetage des applications et le déploiement sont très importants) un mauvais exemple de la façon dont SQL Server, Reporting Services, Sharepoint et webservices pourraient être installés.

TFS peut importer à partir de SVN, mais SVN ne peut pas importer à partir de TFS. Donc, si vous ne trouvez pas de bonne raison, utilisez SVN, car il est plus facile de changer d'avis plus tard.

L'une des meilleures choses à propos de SVN est que chaque système de contrôle de code source que je connais peut en importer, donc choisir SVN us une option à très faible risque.

D'après mon expérience SVN global est beaucoup plus rapide et sans douleur. Je l'ai utilisé avec des scripts de déploiement XCOPY qui vous permettent de travailler et de déployer beaucoup plus rapidement dans l'ensemble par rapport à TFS.

Je n'ai pas d'expérience avec TFS, mais L'intégration IDE est quelque chose à laquelle vous devriez penser. TFS intègre évidemment très bien avec Visual Studio. AnkhSVN, le seul plugin gratuit utilisable pour VS, est souvent problématique, même dans les nouvelles versions. Je n'ai pas essayé VisualSVN, cependant.

considèrent que TFS 2010 peut être installé aussi sur Windows Vista / 7 client OSs et qu'il prend en charge une express, trois clics, l'installation.

Pour:

• Intégration avec Visual Studio . Un vrai plus si vous tirez profit d'une technologie Microsoft complète. pile pour le développement.
• Automatisé des builds (si réalisable par d'autres produits) est vraiment bien fait. L'intégration continue et les constructions D'enregistrement sont fantastiques IMO.

Inconvénients:

• Windows Workflow Foundation . Pour une raison quelconque, Windows Workflow Foundation a été choisi comme la méthode pour personnaliser de nombreux aspects de TFS. En bref, vous avez besoin d'un livre sur Windows Workflow pour le comprendre, et je n'ai tout simplement pas le temps. Très décevant de l'OMI.
• Gestion De Projet . Le concept des objets de travail est assez simple je suppose, mais il ya beaucoup de bizarreries avec elle qui laissent juste me coupe le sifflet. C'est juste trop compliqué de l'OMI. Venant d'un contexte Trac + SVN, je préfère beaucoup Trac ici. Encore une fois, juste mon avis.

ne pas comprendre ce dont les outils sont capables, leurs limites, signifie que vous vous retrouvez avec un outil qui ne fonctionne pas pour ce que vous voulez. Comprenez vos exigences, et lisez un peu les manuels de produit - beaucoup d'informations disponibles pour déterminer la pertinence.

bien que je sois entièrement d'accord avec les partisans de SVN, car il s'agit d'un outil glorieux (Je l'ai utilisé à plusieurs reprises à l'Université), j'ai constaté que TFS est généralement plus coopératif dans les situations OOTB lorsque vous utilisez la Version SP1 avec Studio 2010.

de plus, il y a quelques jolis petits plugins qui rendent TFS un peu plus agréable pour ceux d'entre nous qui sont habitués, et préfèrent généralement une solution de type SVN ainsi, et beaucoup d'entre eux ont un excellent support:

TeamReview for Code Review est un exemple: http://teamreview.codeplex.com / MS Voies pour le multi-plate-forme de TFS: http://www.microsoft.com/pathways/teamprise/FAQ.htm

Cela DONC, la Question est une de grandes ressources pour TFS addons: Quels Add-Ons / Utilitaires sont disponibles pour TFS?

Un Mot pour le sage, comme mentionné ci-dessus, TFS peut être une douleur d'être installé, la prudence devrait être exercée. En suivant la route ci-dessous, j'ai rencontré des problèmes minimes:

Studio 2008 -> Patcher -> Studio 2010 -> Patcher -> .NET -> SQL Server 2008RD/2012 -> Patcher -> TFS -> Correctifs