Michel Perfetti [Miiitch]

Branches, bugs, et chef de projet! Ou comment faire voyager les changesets dans le contrôleur de source sans faire de “baseless merge”.

Voici la situation: Bob bosse sur un bug de la version R1 du soft, la correction est prète mais le chef de projet décide que ce bug ne sera pas corrigé dans la V1: la V2 est déjà sorti, et  il ne veux plus que des corrections de sécurité sur la V1. Par contre le bug existe dans la version en cours de développement, il faut donc corriger cette version.

Voici une image du contrôleur de source:

Si c’était possible, il faudrait faire un merge entre la branche R1-BUG_345 et la Main. Mais ce n’est possible qu’en mode baseless (Let me google that for you ). Mais cette opération n’est pas forcément la plus simple car elle n’utilise pas les informations que TFS possède sur l’origine des fichiers: il est tout à fait possible qu’entre la R1 et la Main actuelle, les fichiers qu’il faut fusionner aient été renommés ou déplacés, et là, le baseless merge ne vas pas trop nous aider. Autre possibilité: utiliser le merge de TFS tout en compensant: nous allons effectuer 2 merges jusqu’à la main et ensuite faire en sorte d’annuler nos modifications dans R1 et surtout acter cette modification dans la Main. Pour cela nous allons utiliser la ligne de commande de TFS 2010 (la fonction était dans les powertools dans les versions précédèntes).

Dans Visual Studio j’effecture les opérations suivantes:

• merge R1-BUG_345 –> R1: changeset 22
• merge R1 –> Main du changeset 22 : changeset 23

Maintenant nous avons notre correction dans la main. Il ne reste plus qu’à la supprimer de la branche R1. Pour cela nous allons donc utiliser la commande “tf rollback”:

tf rollback /changeset:C22~C22 /recursive /keepmergehistory

Voici l’état des pending changes:

On remarque bien que l’état est “Rollback”! Regardons l’historique du fichier en question:

J’ai ajouté l’option /keekmergehistory pour indiquer à TFS que je ne veux plus que le changeset 22 soit appliqué si je remerge la branche R1-BUG_345 dans R1.

On pourrait penser que tout est bon maintenant, mais il manque une étape: si je merge la branche R1 dans la Main, le code va être annulé comme dans R1! Il y a maintenant 2 possibilités pour corriger cela:

• Solution 1: faire le merge dans la main et refaire un rollback avec l’option /keepmergehistory: 2 opérations
• Solution 2: faire croire que le merge de R1  vers Main est effectué via un /discard dans le merge: 1 opération.

Prenons la solution 2: tf merge /recursive /discard /version:C24 “$/MSF Agile Test/Release/R1” "$/MSF Agile Test/Main”

Historique devient comme suit:

Les commentaires sont importants pour bien comprendre ce qui s’est passé.

Nous avons donc réussi notre mission: Rien dans R1 et le bug corrigé dans la Main. Un conseil pour ces opérations: travailler si possible sur un seul changeset à la fois ou un groupe de changetset assez proche de la latest d’une branche: cela vous évitera les conflits pour la résolution du code.

J’ai utilisé l’option /keekmergehistory, mais sans cette option le rollback est très utile pour:

• un développeur:  pour annuler un changeset un peut trop rapidement fait,
• pour un gestionnaire de l’usine: pour annuler un changeset qui fait planter la build si le développeur ne peux pas corriger de suite: c’est un peu notre arme anti-plantage de build .

End Of Line