TFS vs SVN

Question

Je suis sur le point de commencer un projet (par.NET), et vous devez décider entre TFS et SVN.

Je suis plus habitué à SVN(avec tortue client), les CV et les VSS. Ne TFS disposer de toutes les fonctionnalités disponibles dans le SVN

N'avez-vous changé à partir de SVN à TFS et a trouvé cela en vaille la peine?
Aussi il semble que nous peut avoir besoin de Visual Studio, si nous avons besoin de travailler avec TFS.

[Modifier]
L'argent n'est pas une considération puisque nous avons déjà les licences de la TSF en place. Et je suis plus intéressé à la Source des fonctionnalités de Contrôle de la TSF vs SVN, bien sûr, d'autres caractéristiques de la liste est également la bienvenue.

Answer 1

"On ne peut pas comparer entre TFS et SVN"

SVN: est Code Source Système de gestion de versions
TFS: est à part entière de Développement de Logiciel de système de Gestion contient, le contrôle de Version, gestion de production, les Exigences de suivi, publication de documents et d'autres choses.

Les deux ont beau utiliser l'IDE de l'intégration add-ins(par exemple AnkhSVN, Collabnet de l'add-in) disponible pour VS2005, si ce n'est pas le point à prendre en compte.

Les critères à considérer pour le choix:
- Si vous avez un pas ou un petit budget, de choisir SVN
- Si vous êtes seulement à la recherche pour le système de contrôle de version choisir SVN, si vous êtes à la recherche pour un développement complet de gestion de choisir TFS
- Si vous avez la patience de jongler avec les différents outils d'intégration (CruiseControl.Net, NUnit, NCover, AJUSTEMENT) pour obtenir un environnement de développement choisissez SVN, ou si vous êtes à la recherche pour sortir de la zone de mise en œuvre de toutes ces pour vous, puis choisissez TFS

Answer 2

Ayant utilisé TFS 18 mois en arrière, je l'ai trouvé buggy, lent, ennuyeux, très peu de critères de recherche et il avait la sensation d'un produit précipité par une équipe de l'onu intéressés, sous payés, plus travaillé que les techniciens d'être contraint à l'utilisation de Sharepoint et d'autres MS technologies parce que c'est ce qu'est le marketing voulu. Sérieusement, il était un chien, j'aurais plutôt utilisé SourceSafe!

SVN sur l'autre main est un peu technophile, intégration EDI est une douleur, et il peut parfois se confondre, mais l'utilisateur de base est massif et le plus problème peut se résoudre avec un rapide AFIN quesition.

Avez-vous envisagé de Voûte? Fonctionne bien, et ce n'est pas trop cher.

Answer 3

Je ne le recommande TFS si vous utilisez la version 2013 et à l'aide de Git en fonction du référentiel. 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 de comparaison à la fois. C'est ridiculement utile lorsque vous souhaitez revoir vos modifications avant de les fusionner et n'est pas disponible.
• Incompatible disponibilité de la fonctionnalité. Certaines fonctionnalité n'est disponible que dans l'IDE, tandis que d'autres pièces sont disponibles uniquement à partir de l'Explorateur Windows, tandis que d'autres encore sont disponibles uniquement à partir de la ligne de commande.
• L'ajout de fichiers à un contrôle de version n'est pas disponible à partir de l'IDE et disponible uniquement à partir de Windows Explorer l'intégration.
• Accès à tablette fixe est disponible uniquement à partir de l'intérieur de l'IDE et ne sont pas disponibles par le biais de l'intégration dans Windows Explorer.
• Le manque d'une seule et même installation. Il ne suffit pas d'installer TFS, vous devez aussi installer équipe des outils et des machines-outils pour obtenir des fonctionnalités de base.
• Plateau jeu de la fonctionnalité ne pas fusionner. Ce qui aurait été une façon cool de faire privé branches, essentiellement des garanties de votre code va sortir de la date et de l'arrêt de travail.
• Vous devez déverrouiller manuellement le texte des fichiers avant de les modifier si vous avez besoin d'utiliser un éditeur autre que Visual Studio.
• Parfois, Visual Studio oublie de déverrouiller des fichiers qu'il est lui-même la gestion et renvoie une erreur.
• Le check-in et mise à l'écart de l'Isu de la base de fichiers disponibles pour s'engager sur ce qui a déjà été ajouté à TFS et non pas ce qui est effectivement présent dans le système de fichiers. De ce fait, il est 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 qui, en soi, est un autre délire).
• Elle est inutilement difficile d'utiliser les outils de Microsoft pour modifier votre source en raison des problèmes mentionnés précédemment.
• Configuration de TFS est engagé avec votre source. Cela signifie que si vous modifiez votre serveur TFS la configuration pour tous vos histoire est maintenant incorrect. Il y a une configuration par défaut que vous pouvez utiliser qui remplace ce comportement, mais il n'est pas évident.
• Pas de support pour ignorer les filtres de quelque chose, mais le niveau de base.
• L'incapacité à gérer les chemins d'accès 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é. La différenciation entre changé et a déverrouillé le rendrait beaucoup plus facile pour les diffs, ou, mieux encore, de faire disparaître la totalité de l'cassé le déverrouillage du système.
• L'Explorateur Windows recouvrements d'icône ne montrent pas clairement si un fichier a été modifié. Tous les fichiers dans TFS ont un vert coin, tandis que les fichiers modifiés par l'ajout d'un crayon au bas de l'icône. Commutation à coin rouge pour modifié serait beaucoup plus facile à voir ou à l'aide de la tortue système d'icônes.
• 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 version IDE de la dépendance dans le contrôle de source.
• Comprend l'utilisateur de la solution par défaut les fichiers lorsqu'ils ne sont pas nécessaires. Bien sûr, je vais vous avouer que cela pourrait être une question de préférence.
• Mauvaise mise en cache en fait possible que les différences entre votre copie locale et le serveur ne sont pas reflétées de manière précise. C'est extrêmement frustrant pour Obtenir la Dernière et de trouver que vous n'avez pas la dernière.

Answer 4

Il fait 1,5 ans que je suis en utilisant SVN pour divers projets. Les configurations que j'ai utilisé jusqu'à présent:

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

N'ai pas eu de problèmes avec l'un de ces configurations et j'ai vraiment vous recommandons d'utiliser SVN que c'est gratuit et facile à utiliser. Aussi beaucoup de la gestion de projet / suivi des bogues paquets intégrer avec SVN (comme le trac , par exemple).

Answer 5

Je choisirais SVN. J'ai travaillé avec SVN à partir d'un point de vue développeur avant et je travaille actuellement avec TFS, et laissez-moi vous dire que TFS est douloureux. Alors que TFS est la fonctionnalité complète et est plus que juste le contrôle de version, son contrôle de version est bâclée au mieux. La fusion, c'est une horreur et beaucoup d'entre nous tournons maintenant vers la fusion manuelle ou fusionner des outils parce que nous ne pouvons pas compter sur TFS. Les fichiers manquant, ne sont pas téléchargées sur le système local, parfois, et il y a des bizarreries dans son comportement que vous voulez taper la tête contre un bureau.

Cela étant dit, si vous voulez TFS dans toute sa gloire, sont prêts à collaborer avec ses points de douleur, il est un excellent outil pour le programme d'installation automatisée construit, et les rejets.