Je dirais que cela dépend vraiment de vos besoins. TFS est très agréable, je l'ai beaucoup utilisé, mais il est très destiné au niveau de l'entreprise, si vous n'avez pas besoin de toutes ces fonctionnalités, cela pourrait ne pas être nécessaire. Si vous avez besoin de ces fonctionnalités (en particulier la ramification, l'évolutivité, le suivi des éléments de travail, etc.), elles valent chaque centime. Gardez à l'esprit que TFS inclut le suivi des bogues, le suivi des éléments de travail et d'autres fonctionnalités au-delà du contrôle de la source. Si vous avez plusieurs branches ou si vous vous battez contre un manque de fonctionnalités ou autre dans Subversion, il peut être judicieux de changer. Mais à moins d'avoir une bonne raison de changer, vous devriez probablement éviter l'impact sur les coûts et la productivité du changement de système de contrôle de source.

Je suis surpris que quelqu'un qui a utilisé Subversion dans le passé ait même envie/besoin d'un contrôle de source TFS.

Mon expérience avec TFS (2005) a été assez horrible. J'ai lu toutes sortes de livres blancs

TFS n'est pas qu'une question de contrôle de code source. Si vous utilisez l'ensemble du package proposé par TFS, le suivi des bogues, les builds, les rapports, etc., TFS est un choix assez solide (certainement meilleur que Rational). TFS s'intègre également bien à Active Directory.

Bien que si vous ne parlez que de SCM, je préfère SubVersion. Je n'aime pas vraiment l'intégration IDE. J'aime aussi la convention SVN de la structure Trunk/Tags/Branches et la facilité relative de basculer entre les branches. La fusion semblait cependant plus facile dans TFS. L'interface utilisateur de Tortoise bat les mains de TFS, en particulier en ce qui concerne l'ajout d'un fichier à un dépôt.

Comme d'autres l'ont souligné, TFS vous offre beaucoup plus de fonctionnalités que SVN 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, effectuez une mise à niveau vers TFS 2008. Vous me remercierez. Il y a une tonne d'améliorations dans TFS 2008 qui le rendent fonctionnel.

2) Si vous vivez dans Visual Studio et que vous souhaitez l'intégration IDE, optez pour TFS. J'ai utilisé l'intégration SVN et j'ai presque toujours recommencé à utiliser TortoiseSVN.

3) Si vous aimez l'idée que les comptes soient intégrés à l'authentification Windows, optez pour TFS. La gérabilité de cette fin est agréable. Il peut y avoir des crochets pour SVN - je ne suis pas sûr, mais si vous aimez la gestion pilotée par l'interface graphique, TFS est difficile à battre.

4) Si vous avez besoin de suivre des métriques ou si vous avez des moyens plus simples de mettre en œuvre des éléments tels que des politiques d'enregistrement, optez pour TFS.

5) Si vous avez des gens qui ne l'implémenteront pas s'il ne s'agit pas de MSFT, optez pour TFS.

6) Si vous faites plus que .NET (travail Java, Eclipse, etc.), optez pour SVN. Oui, il existe de très bons produits (comme Teamprise) qui fonctionnent bien avec TFS. Mais à moins que les autres langues ne soient une petite partie de votre boutique, restez avec SVN.

En dehors de cela, les fonctionnalités SCM des deux sont à peu près équivalentes. Ils font tous les deux des branchements et des fusions, ils font tous les deux des archivages atomiques, ils prennent tous les deux en charge les changements de nom et les déplacements. Je pense que pour les personnes qui débutent avec le concept de création de branches et de fusion, il est agréable d'avoir les branches visibles dans Source Control Explorer.

TFS n'est vraiment pas si cher (1 200 $ peut-être ?). Comparé à SVN, c'est peut-être le cas. L'intégration aux services de reporting et à SharePoint est agréable, mais encore une fois, si vous ne l'utilisez pas, cela n'a pas d'importance.

Ce que je dirais, c'est de télécharger la version d'essai de 180 jours de TFS et de l'essayer. Exécutez un essai côte à côte. Je pense que vous serez heureux, peu importe la direction que vous prendrez.

Si tout ce dont vous avez besoin est le contrôle de la source, TFS est exagéré. L'un de mes précédents employeurs avait TFS, VSS et Subversion dans son entreprise. Nous n'avions pas Active Directory ou Exchange Server 2003 dans notre entreprise, nous avons donc fini par créer des utilisateurs distincts sur le serveur TFS afin que les développeurs puissent l'utiliser. Nous avons eu les mêmes types de problèmes avec la fusion que Ben Schierman a mentionnés, ainsi que d'autres comportements buggés qui nous ont poussés vers Subversion.

La question de savoir si TFS est la bonne solution 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/la maintenance de votre solution. Si vous souhaitez bénéficier des fonctionnalités supplémentaires de suivi des problèmes, des éléments de travail et des statistiques de projet fournies par TFS, il peut être utile d'examiner d'autres alternatives. Des produits comme JIRA (d'Atlassian Systems) ou Trac s'intègrent bien à Subversion et offrent le type de supervision qu'un chef de projet ou de programme pourrait offrir à un prix inférieur.

Dans un environnement idéal, avec Active Directory, Exchange Server 2003 ou supérieur et un personnel dédié au référentiel, TFS est plus susceptible d'être un bon choix.