Un contrôleur de source, ce n’est pas un simple système de fichiers!
Cela peut sembler évident, mais tout le monde n’est pas sensibilisé à cela: toute opération sur une branche va se répercuter sur les branches parentes lors des merges. Il faut donc, lorsque l’on réalise une opération dans une branche, penser que cela aura des répercutions bien plus tard!
Il n’oublie jamais! 
Voici un exemple (vécu):
Gérard est un développeur de l’équipe, on lui a assigné un bug le #567 sur l’application App_X qui est dans la release R3 du soft. Jusque là: rien d’anormal. Gérard tire une branche de toute la release pour réaliser sa correction, y compris App_Y qui n’a rien à voir avec le bug.
Gérard ce dit que c’est idiot de voir pour la correction les 2 projets. On va alors croire que la correction est à la fois dans App_X et App_Y. Gérard décide alors de supprimer App_Y dans sa branche: simple “nettoyage”. Gérard choisit donc d’effectuer un “delete” sur App_Y:
Cela donne alors cet état:
Tout a l’air OK comme cela. Gérard corrige le bug et merge dans la release. Et là, c’est le drame:
Comme je le disais au début: TFS (comme toute contrôleur de source) n’oublie rien. Le delete n’était pas la solution (le “delete” n’est généralement pas la bonne décision!). Qu’aurait du faire Gérard?
Déjà Gérard aurait du avoir l’option suivante activée:
Il aurait alors vu que le dossier était marqué comme supprimé dans TFS. Cela lui aurait surement mis la puce à l’oreille:
Gérard avait en fait 2 options:
- ne rien faire (des fois c’est la meilleur des options): pour une branche le plus important ce ne sont pas les fichiers que l’on a branché, mais ce qu’il y a dans l’historique.
- demander une destruction du projet dans sa branche: contrairement au “delete” qui crée une opération pour supprimer des fichiers. La destruction de fichiers fait comme si les fichiers détruits n’avaient jamais existé, donc aucun historique!
Cela ce passe en ligne de commande:
Et donc au moment du “merge”: aucune opération d’effacement est crée:
Contrairement à un “delete”, le “destroy” est irréversible et est réservé que dans ces cas exceptionnels. De même un “delete” doit rester rare: supprimer un fichier revient à supprimer du code, donc supprimer de la valeur et surtout perdre l’historique. Cela est d’autant plus vrai pour un projet complet. Il est plus interessant de créer un dossier spécifique qui recevra l’ensemble des projets décommissionnés plutot que de les détruire et de marquer ce dossier en lecture seule.
Alors comment identifier ces changesets qui peuvent contenir ce genre d’opérations. Généralement je les retrouve avec les commentaires suivants: “cleaning”, “refactoring”… et tout ce qui peut induire des changements dans la structure du code.
Bonne chasse!
End of line
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
