On peut supprimer des fichiers dans le Source Control, mais le Team Explorer ne nous propose pas de les détruire. Par « détruire », on parle ici d'un équivalent du « Destroy permanently » de Visual Source Safe.

En effet, lorsque l'on supprime un fichier, il est simplement noté comme « Supprimé » dans le Source Control. Si on le détruit, il est physiquement supprimé du Source Control et on ne pourra plus le récupérer.

tf destroy $/MyTeamProject/MyItem.cs

TFS nous permet de faire un "Undo Check-Out" sur les fichiers sur lesquels nous avons pris la main, autrement dit d'annuler nos modifications locales.

Cependant nous ne pouvons faire ceci via l'interface de Visual Studio que sur les fichiers pour lesquels nous avons fait un « Check-Out » sur la machine courante.

Si nous voulons annuler nos modifications en cours sur une autre machine, nous devons pour cela utiliser une ligne de commande :

tf undo /workspace:MonWorkspace;MonLogin $/MyTeamProject/MyItem.cs

Nous pouvons également utiliser une option « /recursive » de façon à travailler au niveau d'un répertoire.

Une bonne pratique avant de livrer une version est de vérifier que plus aucun développeur n'a du travail en cours, ou des fichiers « oubliés » sur une machine. Autrement dit, s'assurer qu'il n'y a plus aucun fichier en « Check-Out » qui devrait être remonté sur le serveur.

Pour cela, on peut utiliser la commande « status » :

tf status $/MyTeamProject /recursive /user:*

On peut réduire la recherche à un élément particulier (un répertoire ou un fichier) en précisant le chemin complet de l'élément, et non pas en se contentant d'indiquer le nom du Team Project.

On peut également se restreindre à un utilisateur particulier en remplaçant l'« * » par le login de l'utilisateur.

Notez que l'on peut utiliser une option supplémentaire : « /format:detailed » de façon à obtenir plus d'informations sur les fichiers en check-out :

Nous n'avons pas abordé le point des « check-in polocies » dans ce document. En quelques mots, cela permet de définir des règles à respecter avant de pouvoir remonter (faire un check-in) des fichiers dans le Source Control. Deux exemples typiques : « ajouter un commentaire lors de la remontée » et « que tous les tests aient été exécutées et soit réussis ».

Pour ajouter une check-in policy, il suffit d'aller dans le Team Explorer et de faire un clic droit sur le Team Project pour sélectionner « Team Project Settings » puis « Source Control ». L'onglet « Check-in Policies » nous permet alors de configurer les policies que l'on veut utiliser sur notre projet.

Comme Visual Studio et le Team Foundation Server sont totalement extensibles, il est également possible de créer vos propres « Check-in Policies ».
Néanmoins, cela nécessite de rentrer dans le modèle objet du TFS, et dépasse donc le cadre de ce document.

Les Power Tools vont également lister les différents membres d'un Team Project. Sur chaque membre, on trouvera un menu contextuel nous offrant les options suivantes :

• Visualiser la liste des check-in réalisés
• Visualiser la liste des shelvesets (12)
• Visualiser la liste des fichiers actuellement en check-out, et ce quel que soit le workspace de la personne

La liste des fichiers en check-out nous permet alors de faire facilement des « Undo » sur ces fichiers, pour autant que l'utilisateur en ait le droit.

Il est tout à fait possible dans le Team Foundation Server d'ajouter des alertes, c'est à dire typiquement d'envoyer des mails lorsqu'un événement se produit sur le serveur.

Deux alertes typiques :

• avertir lorsqu'un build se termine (et qu'il échoue)
• avertir si un utilisateur fait un check-in de certains fichiers (typiquement s'ils sont impactant pour d'autres utilisateurs

Une alerte se base sur une requête sur différents tables et champs du TFS.