TFS vs SVN

Je suis sur le sharepoint démarrer un projet (.NET) et je dois choisir entre TFS et SVN.

Je suis plus habitué à SVN (avec client tortue), CVS et VSS. TFS a-t-il toutes les fonctionnalités disponibles dans SVN?

L’un d’entre vous est-il passé de SVN à TFS et l’a-t-il trouvé intéressant?
De plus, il semblerait que nous ayons besoin de Visual Studio si nous devons travailler avec TFS.

[Modifier]
L’argent n’est pas une considération puisque nous avons déjà les licences pour TFS en place. Et je suis plus intéressé par les fonctionnalités de contrôle de code source de TFS vs SVN, bien sûr, d’autres listes de caractéristiques est également la bienvenue.

Eh bien, pour moi, le choix est évidemment TFS:

  • L’intégration de SVN dans Visual Studio est pour le moins incomplète (de nombreuses fonctionnalités ne sont pas disponibles dans l’EDI) et un peu bogué (AnkhSVN l’est certainement), alors que TFS one est parfait (ce qui est logique …). Tout mon espace de travail a été corrompu plusieurs fois en utilisant SVN (pendant un mois), sans utiliser TFS (environ 2 ans)

  • Bien que les fonctionnalités liées au contrôle de source des deux systèmes soient probablement tout à fait équivalentes, elles sont accessibles directement depuis l’EDI avec TFS, alors que vous devez utiliser TortoiseSVN ou d’autres outils externes si vous utilisez SVN. Presque toutes les tâches TFS sont accessibles en quelques clics sur l’onglet Explorateur de solutions.

  • La fusion est beaucoup plus facile avec TFS, même pour les fusions complexes (par exemple, SVN appenda <<<<<< 's et >>>>>>>>> à vos fichiers .csproj , vous aurez donc besoin de pour les éditer manuellement pour les ouvrir à nouveau depuis VS.)

Bien que je pense que ces raisons sont plus que suffisantes pour préférer TFS à SVN, je dois append que:

  • TFS est plus qu’un simple outil de contrôle des sources (pensez aux éléments de travail, au portail du projet, etc.)

    Je l’ai utilisé sur un projet de taille moyenne (12 codeurs, 3 testeurs, 3 analystes) et nous avons réussi à centraliser toutes les tâches dans TFS (rapports de bogues, documentation du projet, processus de génération, etc.). etc.)

    Je ne dis pas qu’il n’est pas possible de faire la même chose en utilisant SVN et d’autres outils tiers, mais c’est bien d’avoir toutes les fonctionnalités bien intégrées dans un seul produit.


Pour restr juste, voici les deux inconvénients évidents de TFS:

  • Son prix

  • L’installation de TFS est assez pénible, alors que l’installation de SVN ne prend que quelques minutes.

    Installer TFS 2008 sur SqlServer 2008 est assez compliqué, vous ne pouvez pas installer TFS sur un PDC, etc. Pour moi, c’est définitivement la pire expérience d’installation que j’ai jamais eue avec un produit Microsoft.

    Cela étant dit, une fois installé, TFS est très facile à utiliser (en particulier pour les codeurs qui ne sont pas familiarisés avec les systèmes de contrôle des sources)


Dans mon projet actuel, j’ai commencé avec SVN et je suis rapidement passé à TFS. Je suis content de l’avoir fait.

La principale raison pour laquelle j’ai décidé de changer est clairement le comportement général de SVN (j’utilisais VisualSVN en tant que serveur et AnkhSVN en tant que client). Au moins une fois par semaine, je me suis retrouvé à passer des heures sur des messages d’erreur cryptiques AnkhSVN.

À ce jour, je n’ai trouvé aucune raison de regretter le passage à TFS.

On ne peut pas comparer entre TFS et SVN

SVN : est le système de gestion de version du code source
TFS : est un système de gestion de développement logiciel à part entière qui contient, contrôle des versions, gestion des versions, suivi des exigences, publication de documents, etc.

Les deux ont la possibilité d’utiliser des compléments d’intégration IDE (par exemple AnkhSVN, le complément de Collabnet) disponibles pour VS2005, ce n’est donc pas le point à considérer.

Critères à considérer pour le choix :
– Si vous avez un projet à petit budget ou pas, choisissez SVN
– Si vous recherchez uniquement un système de contrôle de version, choisissez SVN , si vous recherchez une gestion complète du développement, choisissez TFS
– Si vous avez de la patience pour jongler avec différents outils d’intégration (CruiseControl.Net, NUnit, NCover, FIT) pour obtenir un environnement de développement approprié, choisissez SVN , ou si vous recherchez une implémentation complète, choisissez TFS.

Ayant utilisé TFS il y a 18 mois, je trouvais qu’il y avait des critères de recherche bogués, lents, gênants et très limités, et qu’une équipe de techniciens non intéressés, mal payés et travaillant Les technologies MS parce que c’est ce que le marketing voulait. Sérieusement c’était un chien, j’aurais plutôt utilisé SourceSafe!

SVN, par contre, est un peu technique, l’intégration IDE est difficile et peut parfois être source de confusion, mais la base d’utilisateurs est massive et la plupart des problèmes peuvent être résolus avec une requête SO rapide.

Avez-vous pensé à Vault ? Fonctionne bien et n’est pas trop cher.

Je recommande uniquement TFS si vous utilisiez la version 2013 et utilisez le référentiel basé sur Git. J’ai rencontré trop de problèmes avec les versions précédentes pour les considérer stables.

  • Il est impossible d’envoyer plusieurs fichiers à votre outil de diff à la fois. Ceci est ridiculement utile lorsque vous souhaitez revoir vos modifications avant une fusion et qu’elles ne sont pas disponibles.
  • Disponibilité incohérente des fonctionnalités. Certaines fonctionnalités sont disponibles uniquement dans l’EDI, tandis que d’autres ne sont disponibles qu’à partir de l’Explorateur Windows, tandis que d’autres ne sont disponibles qu’à partir de la ligne de commande.
  • L’ajout de fichiers au contrôle de version n’est pas disponible à partir de l’EDI et n’est disponible qu’à partir de l’intégration de Windows Explorer.
  • L’access aux ensembles d’étagères n’est disponible qu’à partir de l’EDI et n’est pas disponible via l’intégration de Windows Explorer.
  • Absence d’un seul installateur unifié. L’installation de TFS ne suffit pas, vous devez également installer des outils d’équipe et des outils élecsortingques pour obtenir des fonctionnalités de base.
  • La fonctionnalité de jeu d’étagères ne fusionne pas. Ce qui aurait pu être un moyen génial de créer des succursales privées, garantit essentiellement que votre code sera obsolète et cessera de fonctionner.
  • Vous devez déverrouiller manuellement les fichiers texte avant de les modifier si vous devez utiliser un éditeur autre que Visual Studio.
  • Parfois, Visual Studio oublie de déverrouiller des fichiers qu’il gère lui-même et génère une erreur.
  • L’interface utilisateur d’archivage et de mise en attente base les fichiers disponibles pour une validation 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 à rater des fichiers. (Ceci est en fait un problème avec la façon dont Visual Studio gère les fichiers de projet, mais cela en soi est un autre problème).
  • Il est inutilement difficile d’utiliser des outils non Microsoft pour modifier votre source en raison des problèmes mentionnés précédemment.
  • La configuration de TFS est validée avec votre source. Cela signifie que si vous modifiez votre serveur TFS, la configuration de tout votre historique est désormais incorrecte. Il existe une configuration par défaut que vous pouvez utiliser et qui remplace ce comportement, mais ce n’est pas évident.
  • Aucun support pour ignorer les filtres à tout sauf le niveau de base.
  • Impossibilité de gérer des chemins de plus de 249 caractères.
  • Les fichiers qui ont été déverrouillés, mais pas édités, apparaissent comme modifiés, même s’ils ne l’ont pas été. Différencier les modifications et les déverrouillés faciliterait grandement les diffs, ou mieux encore en supprimant entièrement le système de délocking cassé.
  • Les superpositions d’icons de Windows Explorer n’indiquent pas clairement si un fichier a été modifié. Tous les fichiers dans 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 modifier serait beaucoup plus facile à voir ou à utiliser le système de tortues des icons.
  • Les anciennes versions de Visual Studio rencontrent 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 des sources.
  • Inclut les fichiers de solution utilisateur par défaut lorsqu’ils ne sont pas nécessaires. Bien sûr, je dois admettre que celui-ci pourrait être une question de préférence.
  • Une mise en cache incorrecte permet de ne pas refléter correctement les différences entre votre copie locale et le serveur. Il est extrêmement frustrant d’obtenir les dernières nouvelles et de constater que vous n’avez pas les dernières données.

Cela fait maintenant 1,5 ans que j’utilise SVN pour divers projets. Les configurations que j’ai utilisées jusqu’à présent:

  • Client AnkhSVN pour Visual Studio. Il s’intègre bien en tant que fournisseur de contrôle de code source depuis la version 2.
  • Serveurs Subversion CollabNet sous Windows ou Apache 2.2 avec SSL + SVN via DAV sous linux.

Je n’ai eu aucun problème avec ces configurations et je recommande vivement d’utiliser SVN car c’est gratuit et facile à utiliser. De plus, de nombreux paquets de gestion de projet / suivi de bogue s’intègrent à SVN (comme trac par exemple).

Je choisirais SVN. J’ai travaillé avec SVN du sharepoint vue du développeur auparavant et je travaille actuellement avec TFS, et laissez-moi vous dire que TFS est pénible. Bien que TFS soit plein de fonctionnalités et ne se limite pas au contrôle de version, son contrôle de version est au mieux négligeable. La fusion est épouvantable et beaucoup d’entre nous se tournent maintenant vers des outils de fusion ou de fusion manuelle car nous ne pouvons pas compter sur TFS. Les fichiers disparaissent, ne sont pas téléchargés sur le système local parfois, et il y a juste des bizarreries dans son comportement qui vous donnent envie de vous cogner la tête contre un bureau.

Cela étant dit, si vous voulez TFS dans toute sa splendeur, êtes prêt à travailler avec ses points critiques, c’est un excellent outil pour configurer des versions automatisées et des versions.

J’ai utilisé les deux, mais en fait, j’ai passé de TFS à SVN dans mes projets principaux. Je trouve l’access hors ligne et anonyme très précieux dans mes projets.

En général, je pense qu’ils sont comparables. Je voudrais juste choisir celui que vous connaissez le mieux, et vous êtes le plus heureux du maintien. Je ne trouve pas les fonctionnalités spécifiques dans un surpoids considérablement les fonctionnalités de l’autre système.

Consultez cet article avant de décider: une comparaison entre TFS et Subversion pour les projets Open Source

Si vous êtes familier avec svn, je m’en tiendrai à cela. Tfs n’est pas gratuit et n’est pas simple. Il fait beaucoup plus que le simple contrôle des sources. Si vous êtes un magasin .net comme nous et que vous décidez du produit à utiliser pour tout le cycle de développement, c’est un concurrent, mais pour un contrôle de source simple, c’est exagéré.

Je dirais que TFS est plus qu’un simple contrôle de source. Si vous pouvez vous le permettre, je vous conseille vivement de l’utiliser. Lorsque vous commencez à utiliser Team Builds, par exemple, ou utilisez des éléments tels que Work Items, vous verrez que TFS peut réellement gérer l’intégralité de votre cycle de développement en fournissant un environnement riche dans lequel la génération de rapports, la facilité d’utilisation, l’intégration VS le contrôle est tout en un.

Il nécessite du fer du côté du serveur. Je ne trouve pas cela lent, cependant, il fonctionne bien sur VPN et supporte le travail hors ligne.

Un problème majeur est le processus d’installation (côté serveur) qui est fastidieux, non flexible et dans mon esprit (je viens d’un domaine où le conditionnement d’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 depuis SVN, mais SVN ne peut pas importer depuis TFS. Donc, si vous ne trouvez pas une bonne raison, utilisez SVN, car il est plus facile de changer d’avis plus tard.

Une des meilleures choses à propos de SVN est que tous les systèmes de contrôle de code source que je connais peuvent en importer, alors choisir SVN comme option à très faible risque.

Dans mon expérience, SVN est globalement beaucoup plus rapide et indolore. Je l’ai utilisé avec les scripts de déploiement XCOPY qui vous permettent de travailler et de déployer beaucoup plus rapidement que TFS.

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

Considérez que TFS 2010 peut être installé également sur les systèmes d’exploitation Windows Vista / 7 et qu’il prend en charge une installation express, trois clics.

Avantages:

  • Intégration avec Visual Studio . Un réel plus si vous exploitez une technologie Microsoft complète. emstackr pour le développement.
  • Les builds automatisés (bien que réalisables via d’autres produits) sont vraiment bien faits. L’continuous integration et les builds d’archivage Gated sont fantastiques.

Les inconvénients:

  • Windows Workflow Foundation . Pour une raison quelconque, Windows Workflow Foundation a été choisi comme méthode de personnalisation 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 IMO.
  • Gestion de projet Le concept d’éléments de travail est assez simple, je suppose, mais il y a beaucoup de bizarreries avec lui qui me laisse perplexe. C’est juste trop compliqué à mon avis. Venant d’un arrière-plan Trac + SVN, je préfère beaucoup Trac ici. Encore une fois, juste mon avis.

Ne pas comprendre ce que les outils sont capables, leurs limites, vous vous retrouverez avec un outil qui ne fonctionne pas pour ce que vous voulez. Comprenez vos exigences et lisez un peu les manuels des produits – beaucoup d’informations disponibles pour déterminer l’aptitude.

Bien que je sois tout à fait d’accord avec les partisans de SVN, car c’est un outil génial (je l’ai utilisé plusieurs fois à l’université), j’ai trouvé que TFS était généralement plus coopératif dans les situations OOTB 2010

De plus, il existe de bons 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, et beaucoup d’entre eux ont un excellent support:

TeamReview for Code Reviewing est un exemple: http://teamreview.codeplex.com/ MS Pathways pour une utilisation multi-plateforme de TFS: http://www.microsoft.com/pathways/teamprise/FAQ.htm

Cette question est une excellente ressource pour les addons TFS: Quels sont les add-ons / utilitaires disponibles pour TFS?

Un mot à la sagesse, comme mentionné ci-dessus, TFS peut être difficile à installer, il faut donc faire preuve de prudence. Suite à l’itinéraire ci-dessous, j’ai rencontré des problèmes minimes:

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