Comment voir si une branche contient une correction de bogue dans Perforce?

Question

(je suis un nouvel utilisateur de Perforce, mais ont utilisé beaucoup d'autres systèmes de contrôle de code source dans le passé.)

Nous utilisons une liste de changements pour vérifier dans chaque correction de bug; le commentaire de la liste de changement inclut l'ID de bogue donc il est facile de suivre quand une correction de bogue a été vérifiée dans une branche.

Cependant, je ne peux pas voir un moyen facile de trouver toutes les branches d'un correctif donné a été fusionné en, ou de trouver toutes les corrections de bogues qui ont été fusionnés dans une branche donnée. Pour autant que je sache, perforce ne suit pas toutes les branches dans lesquelles une liste de modifications a été fusionnée. Si je comprends bien, quand une fusion est faite dans perforce l'histoire n'est pas copiée dans la branche cible donc la seule histoire dans la cible dans le commentaire sur la liste de changement dans laquelle la fusion a été faite.

Qu'est-ce qui me manque?

Answer 1

Les pistes Perforce où les révisions d'un fichier ont été intégrées, mais il ne propage pas automatiquement les commentaires d'archivage avec vos métadonnées de suivi des bogues.

Étant donné une liste de modifications sur une branche particulière, vous pouvez dire si Perforce pense que la liste de modifications a été intégrée en demandant à Perforce d'intégrer la liste de modifications. (J'utilise "branche" dans le sens plus traditionnel de contrôle de source, pour signifier une branche particulière de l'arbre de code source, plutôt que dans le sens spécifique de Perforce pour signifier le chemin d'intégration entre ces deux arbres de code source.) disons que vous avez travaillé dans //source/project/trunk/... et que vous avez une liste de modifications @ 1234 que vous souhaitez vérifier si elle a été intégrée dans votre branche de publication //source/project/rel/.... Créer un client qui associe //source/project/rel/... et exécuter:

$ p4 integrate -n //source/project/trunk/...@1234,1234 //source/project/rel/... 

Si Perforce vous dit « Toute révision (s) déjà intégrée. », Changelist @ 1234 a été intégré, et que bugfix devraient être disponibles sur la branche de sortie. Si Perforce répertorie les fichiers qui ont été modifiés, ces fichiers n'ont pas été intégrés. (Il est également possible que certains fichiers d'une liste de modifications soient intégrés et pas d'autres, ce qui peut causer des problèmes intéressants.)

Cela ne fonctionne pas particulièrement bien - vous devez vérifier chaque correction de bogue sur chaque branche qui vous intéresse à propos, bien qu'il se prête à l'automatisation.

Vous pouvez utiliser la commande Perforce «non prise en charge» interchanges pour avoir une idée rapide des modifications qui n'ont pas été intégrées d'une branche à une autre. (Dans le langage Perforce, "non supporté" signifie quelque chose comme "pourrait ne pas fonctionner de la même manière dans la prochaine révision, mais nous pensons qu'il pourrait être utile pour que nous le lâchions de toute façon".) Pour voir quels changelists n'ont pas été intégrés tronc d'exemple pour libérer les branches, exécutez:

$ p4 interchanges //source/project/trunk/... //source/project/rel/... 
Change 1236 on 2010/10/10 by user@client 'Fixed some bug you don't care about' 
Change 1235 on 2010/10/09 by user@other_client 'Fixed some other random bug' 

Dans cet exemple, je ne l'ai pas énuméré @ changelist 1234, car il a déjà été intégrée dans la branche de sortie. Un problème que j'ai rencontré en utilisant interchanges est qu'il listera chaque nouvelle révision après une modification non intégrée, même si les nouvelles révisions ont été intégrées, donc si vous choisissez des révisions pour une branche de publication, vous verrez peut-être les listes de changements . J'utilise interchanges comme premier passage pour avoir une idée approximative de ce que j'ai besoin d'intégrer, puis regarde integrate pour avoir une meilleure idée de ce qui manque vraiment.Perforce supporte également un concept similaire de "jobs", qui permet d'attacher des correctifs particuliers à des changelists particulières, mais mon organisation ne les utilise pas, donc je ne sais pas si elles fonctionnent bien ou si elles sont propagées automatiquement sur l'intégration.)