Depuis peu, j’utilise le service en ligne de contrôle de source de Microsoft :Team Foundation Service. Avant de commencer : je débute sur TFS, aussi je tiens à m’excuser au préalable pour les approximations et les erreurs éventuelles (les remarques constructives sont les bienvenues).

Ce service gratuit, basé sur le Cloud, offre tous les outils nécessaires à la bonne gestion de vos projets en équipe et ce, jusqu’à 5 personnes. Toutes les technologies et les langages sont acceptés et pour les habitués de GitHub, il est possible de créer des projets qui utilisent ce contrôleur de source.

Pour l’instant, je découvre le service et je suis le seul à développer sur mes projets. Aussi, lundi soir, quelle ne fut pas ma surprise de constater que mes fichiers étaient à l’état « Lock » (car je n’ai évidemment rien demandé) et qu’il m’était impossible de check-in mes modifications (depuis le PC1). Après investigation, mes fichiers étaient verrouillés par moi-même mais sur une autre machine (que l’on nommera PC2 et à laquelle je n’avais pas accès à ce moment-là) et bizarrement, je n’étais pas en mesure de déverrouiller mes fichiers depuis le PC1. D’après ce que j’ai compris, les verrous sont liés au workspace et non à l’utilisateur, ce qui est parfaitement logique, car c’est sur la machine que se trouve les modifications.

Ne connaissant pas trop l’administration de TFS, j’ai cherché, sans succès, à débloquer la situation dans la console de gestion en ligne du service (vérification des droits, fonctionnalités en ligne, etc.). Je me suis tourné vers le savoir collectif global et, même si mon problème n’était documenté nulle part, j’ai compris que la résolution de mon problème passerait par l’invite de commande développeur pour VS2012 (Developer Command Prompt for VS2012 en anglais, DCP ci-après).

Sur le PC1, j’ai notamment exécuté les deux commandes ci-dessous :

> tf lock /lock:checkin /workspace:PC1 $/Project1 /recursive  /collection:https://user.visualstudio.com/defaultcollection

Cette commande (« tf lock ») permet d’appliquer un verrouillage sur les check-in (grâce au paramètre « /lock:checkin ») tous les fichiers situés dans le dossier $/Project1, de manière récursive. Le fait de préciser la collection est optionnel : elle permet de déterminer quel serveur cibler quand il y en a plus d’un dans le même workspace. Ici, j’ai tenté de récupérer le verrou (mais bien entendu, ce cas de figure est géré et interdit).

Résultat obtenu : Unable to perform operation on $/Project1. The item $/Project1/BuildProcessTemplates/AzureContinuousDeployment.11.xaml is locked in workspace PC2;Username.
Cette erreur m’a indiqué d’où venait le problème et sur quelle machine le workspace était à l’état « Lock ». Pour information : lorsque l’on check-out un projet directement sans préciser le nom du workspace, c’est le nom du PC qui est utilisé (ici « PC2 »).

> tf lock /lock:none /workspace:PC2 $/Project1/ /recursive  /collection:https://user.visualstudio.com/defaultcollection

Cette commande permet d’effectuer un déverrouillage (paramètre « /lock:none ») mais cette fois sur le workspace qui est à l’origine du verrouillage.

Résultat obtenu :TF400032: The operation could not be completed because the workspace PC2;Username is a local workspace.
Cette erreur m’a confirmé que le verrouillage se situait bien sur le PC2 et qu’il ne m’était pas possible de le faire sauter ailleurs que sur la machine PC2.

Dès que j’ai eu accès à PC2, j’ai pu exécuter les deux commandes suivantes :

> tf lock /lock:none /recursive $/Project1 /workspace:PC2 /collection:https://user.visualstudio.com/defaultcollection

Cette commande m’a permis de déverrouiller les fichiers de $/Project1, sans aucun soucis cette fois-ci !

> tf workspace PC2

Celle-ci permet d’ouvrir la fenêtre de gestion du workspace PC2. De là, j’ai pu faire sa fête à ce workspace qui m’a pourri 2 soirées et une partie de ma journée !

A l’heure de la rédaction de ce billet, je ne sais pas trop ce qui a déclenché ce verrouillage de fichier. Ma piste la plus sérieuse est une mauvaise manipulation du check-out causée par un excès de noobisme dans le skill de l’utilisateur.

Vous pouvez maintenant fermer cet onglet et retournez à votre code !
A ciao, bonne journée !