TFS 2010 Basic (beta 2) versus Subversion et al

Question

Pour un développeur solo utilisant Visual Studio 2010 bêta 2, TFS Basic est-il une meilleure option que Subversion (avec VisualSVN ou Ankh) et (éventuellement) quelque chose comme Cruisecontrol?

Je n'ai pas besoin d'une source distribuée ni même d'un accès distant. Je ne me soucie pas vraiment des forages et de tous ces rapports. Je veux juste le contrôle de version & amp; tests potentiellement automatisés & amp; bâtiment.

EDIT: pour répondre aux questions de Bob Aman (Merci Bob)

J'envisageais de m'auto-héberger mais hors site est une bonne idée, comme vous dites. Je sauvegarde régulièrement. Ce n’est vraiment que moi qui aurai accès au référentiel pour que le contrôle d’accès ne soit pas compliqué. J'ai un abonnement MSDN, le coût n'est donc pas un problème. Le référentiel ne deviendra pas particulièrement volumineux - je ne suis pas très productif. : /

Answer 1

Dépend beaucoup de deux facteurs. Vous hébergez vous-même le référentiel ou vous le sous-traitez à une entreprise qui le gère pour vous? (Fortement recommandé, car cela signifie généralement que vous bénéficiez d'une sauvegarde et d'une redondance hors site à moindre coût. Ce qu'il peut parfois être difficile de faire correctement.) Il est beaucoup plus facile de trouver un hébergement stellaire pour Subversion. Je crois qu'il n'y a qu'une ou deux options sur le marché pour l'hébergement TFS. Combien de personnes auront accès au référentiel? Avez-vous besoin de définir des autorisations sur des parties du référentiel? Comment voulez-vous gérer le contrôle d'accès? Si vous avez besoin de faire quelque chose de particulièrement compliqué, c'est soit impossible dans TFS, soit très coûteux. Subversion peut généralement y faire face, même s’il n’est pas toujours facile à configurer.

Presque tout ce que le contrôle de version de TFS peut faire peut également être fait sur Subversion, directement ou à l’aide d’un outil supplémentaire. Subversion s'intègre également assez bien à Visual Studio, même si personnellement, j'ai toujours préféré TortoiseSVN. C'est aussi beaucoup moins cher, en supposant que vous ne possédez pas déjà de TFS via des abonnements MSDN.

Toutefois, si vous entrez dans les extrêmes du contrôle de version (référentiels absurdement gigantesques ou binaires gigantesques dans le référentiel, par exemple), ce que vous voulez vraiment, c'est Perforce.

Answer 2

Si vous n’êtes pas une grande entreprise tributaire de Microsoft, je recommanderais Subversion.

Le contrôle de source TFS est - comment puis-je mettre cela - malheureux.

Cela fonctionne très bien si la seule chose que vous faites jamais est de travailler dans Visual Studio. Toutefois, dès que vous souhaitez interagir avec ce dernier (par exemple, ajouter un fichier texte ou des fichiers de commandes ne figurant pas dans un fichier de solution Visual Studio), cela devient douloureux et problématique.

Cela est principalement dû au fait que tous les fichiers sont en lecture seule sur le système de fichiers, sauf si vous les extrayez explicitement. Visual studio le fait automatiquement, mais pour tout le reste, vous devez toujours extraire explicitement les fichiers à l'aide de la ligne de commande tf.exe ou des outils électriques TFS. Cela devient vraiment très agaçant très rapidement.

Un autre effet secondaire est le suivi des nouveaux fichiers. Subversion et al. Vous informeront des nouveaux fichiers et répertoires non suivis lorsque vous effectuerez un diff, tandis que TFS les ignorera entièrement. Cela a conduit à de nombreuses versions cassées, car un développeur a oublié d’archiver un nouveau fichier, car pour TFS, il n’existait pas du tout tant qu’ils ne l’avaient pas explicitement ajouté.

TFS est également fortement lié au modèle de domaine Windows de l'authentification de l'utilisateur. Vous devez ajouter des comptes d’utilisateur Windows pour que les utilisateurs y aient accès, ce qui est difficile si vous n’exécutez pas déjà votre travail sur un réseau de domaine d’entreprise.