TFS - effectuer un check-out + check-in d'un certain fichier si un autre fichier est en cours d'enregistrement

Question

J'ai des fichiers XSD que je génère des classes pour utiliser l'utilitaire XSD.exe de MS.

J'utilise la pré-construction à l'enregistrement le fichier de classes de code généré et le poste pour vérifier avant.

Comme il y a plusieurs développeurs travaillant sur le même projet et ce qui se passe chaque fois que chacun décide de reconstruire nous continuons à obtenir des conflits sur ce qui n'est pas de vrais conflits (simplement causé par une version de l'outil xsd légèrement différente qui est incluse quelque part dans l'en-tête du fichier cs généré).

Pour résoudre ce problème, je voulais d'abord comparer le contenu de la XSD avec le serveur source et seulement ensuite effectuer l'opération de check-out + check-in.

Existe-t-il un moyen de faire cela en utilisant TFS?

Note: J'ai essayé d'utiliser la commande diff dans le fichier tf.exe mais elle ne retourne pas un code de sortie que je peux utiliser pour connaître le résultat de la comparaison.

Toute aide serait appréciée ...

Answer 1

Vous pouvez utiliser tf.exe et exécutez une commande get pour les fichiers XSD, et si elle retourne « Tous les fichiers sont à jour » vous savez que vous ne Je dois faire le check out/gen/check in traitement

Answer 2

Mon conseil serait de régler la cause du problème plutôt que les symptômes. En cours de développement, vous devriez essayer de faire fonctionner vos développeurs et votre serveur de build avec exactement le même ensemble d'outils et de code source, afin que vous sachiez que vous obtiendrez tous des résultats cohérents. Vous ne pouvez pas garantir que la sortie de deux versions différentes d'un outil sera toujours identique/compatible. Les numéros de version incompatibles simples ne sont pas un problème, mais que se passe-t-il si le programme final que vous générez a des différences subtiles en fonction de qui l'a construit? Fred ne sera peut-être jamais capable de répéter et de corriger le bug dont votre client se plaint. Ou vous pensez peut-être que vous avez corrigé cette vulnérabilité majeure de sécurité ATL jusqu'au jour où vous vous rendez compte que vous avez expédié un produit à partir d'un serveur de build que vous n'avez pas pris la peine de corriger. Il est assez simple d'avoir un processus d'installation standardisé (un document "comment installer" que tout le monde suit attentivement, une boîte contenant le bon ensemble de DVD, et/ou un dossier réseau ou un dossier contrôlé par la source contenant l'ensemble des installateurs à utiliser, des bibliothèques à lier, etc)