2008-10-01 8 views

Répondre

3

Nous avons eu un problème similaire il y a quelque temps. Pour certains sous-arbres, nous voulions entrer un réviseur de code. J'ai fini par implémenter une stratégie personnalisée et utilisé la stratégie de chemin personnalisé pour la restreindre à certains dossiers. Cela fonctionne bien, sauf que vous devez déployer votre assembly de stratégie et TFS n'a pas de mécanisme intégré pour cela, yet.

2

C'est une question intéressante - la réponse courte est que vous ne pouvez pas.

J'ai moi-même souvent rencontré des problèmes d'enregistrement et de check-in parce que, bien que très différents dans leur implémentation sur le serveur, ils servent souvent des objectifs similaires. Les notes d'enregistrement sont des fragments de métadonnées structurées que vous souhaitez collecter à chaque enregistrement dans un projet d'équipe. Ils peuvent penser comme qui était le réviseur de code ou une référence à un ticket dans un système CRM externe ou quelque chose. Vous pouvez les rendre obligatoires, ou simplement les définir pour que les personnes puissent les remplir. Les politiques de check-in sont des bits de code qui s'exécutent sur le client au moment du check-in et qui ont un mot à dire si le check-in doit être autorisé ou non. Elles sont utiles pour vérifier des choses comme si vous avez associé un check-in avec un work item, un commentaire ou le code que vous avez enregistré passe certaines règles d'analyse de code statique (comme la vérification de base des attaques par injection SQL, etc.) . Si une politique d'enregistrement échoue lors de l'évaluation de l'enregistrement, l'utilisateur est averti et obtient la possibilité de résoudre le problème ou de s'enregistrer de toute façon avec une politique de contrôle qui peut facilement être signalée ou alertée. par l'administrateur TFS. Les notes d'arrivée et les politiques d'enregistrement sont définies et délimitées au niveau du projet d'équipe. Toutefois, Microsoft a reçu des commentaires selon lesquels certaines personnes souhaiteraient que les règles d'archivage soient appliquées à des chemins spécifiques dans le contrôle de version plutôt qu'au projet d'équipe. La stratégie de chemin personnalisé a donc été inventée. La stratégie de chemin d'accès personnalisé est un peu un hack qui vous permet d'intégrer des stratégies d'archivage dans la stratégie de chemin d'accès personnalisée. Le chemin personnalisé est évalué à chaque enregistrement et s'il contient des fichiers dans le chemin défini, les stratégies d'archivage encapsulées sont évaluées pour ces fichiers. La stratégie de chemin d'accès personnalisée est fournie dans TFS Power Tools et ne fait pas partie de l'expérience TFS «Out The Box». Donc, pour répondre à votre question d'une manière différente - je pense que la réponse est "parce que c'est comme ça que ça a été conçu et pas assez de gens ont demandé à ce que ça change".

Si vous voulez laisser des commentaires à http://connect.microsoft.com/VisualStudio, je sais qu'ils prennent les commentaires des clients très au sérieux.

Questions connexes