2010-09-29 15 views
5

Dans TFS2010, chaque génération est associée à une étiquette par le serveur de génération.Afficher tous les changesets entre deux étiquettes

Notre équipe de gestion SCM souhaite voir tous les changesets et les work items associés entre deux labels. Généralement, ces étiquettes sont des builds ayant une qualité de construction "Released". De cette façon, tous les changements entre deux versions livrées peuvent être signalés.

Comment cela se passe-t-il dans TFS 2010?

Répondre

4

Je ne pense pas que vous voulez utiliser l'étiquette, je pense que vous voulez utiliser la date/heure de la construction (s). Les étiquettes sont facilement modifiables et ne représentent pas nécessairement un point dans le temps. En supposant que vous avez les datetime des builds, vous pouvez utiliser la ligne de commande TF.EXE pour générer ceci.

Par exemple:

tf.exe history /server:http://tfs:8080 "$/ProjectName/src" /version:D2010-09-12T11:30~D2010-09-29T11:30 /recursive /noprompt /brief 

Le paramètre /version: est l'une des clés ici. Cela devrait être après l'heure de votre première construction et jusqu'à et y compris l'heure de la deuxième construction. Si vous utilisez /format:detailed, vous obtiendrez également une liste de tous les fichiers modifiés dans chacun des changesets. Cela peut être un lot de données. Vous voudrez probablement rediriger la sortie > output.txt si vous faites cela.

MISE À JOUR

Comme mentionné précédemment, vous pouvez, en effet, déterminer les changements entre les deux étiquettes. Cependant, si ces étiquettes ont été déplacées, vos résultats risquent d'être compromis.

Je recommande encore
tf.exe history /server:http://tfs:8080 "$/ProjectName/src" /version:LMain-CI_20100831.6~LMain-CI_20100927.1 /recursive /noprompt /brief 

en utilisant les dates au lieu des étiquettes. Je crois que les résultats que vous recevez de cette approche correspondent probablement mieux à vos besoins.

MISE À JOUR 2

Je viens de remarquer que vous utilisez TFS 2010. Vous devrez probablement modifier le paramètre /server: pour pointer vers la collection appropriée. Utilisez TF.EXE history /? pour obtenir la liste des paramètres, mais le changement serait d'utiliser /collection:TeamProjectCollectionUrl

+0

S'ils sont heureux que rien ne mate réellement les étiquettes, alors les labels de construction générés automatiquement (référencés avec par exemple 'LBuild1234 @ $/TeamProject') seraient plus évidents – AakashM

+0

Le problème vient de décider ce que" entre " étiquettes signifie. Mais, vous avez raison. Je vais éditer ma réponse. – Robaticus

+0

génial! Je vais faire quelques tests aujourd'hui pour vérifier, merci beaucoup! –