Nous gérons nos versions logicielles en tant que branches de Subversion. La dernière version à venir est le tronc. Les versions publiées plus anciennes sont une branche (aussi étiquetée par construction et libération). Lorsqu'un développeur corrige un bogue dans une version plus ancienne, il est de sa responsabilité de fusionner le correctif dans le coffre. Si cette étape est manquée, il est difficile de noter que, peut-être, le bogue apparaît à nouveau dans une version ultérieure. Ensuite, nous devons déboguer et réparer à nouveau.
Y a-t-il un moyen de surveiller les fantasmes pour s'assurer qu'ils sont terminés?
ou y a-t-il un meilleur moyen d'utiliser la ramification de Subversion pour obtenir de meilleurs résultats.
Mise à jour: les personnes pointues de la solution doivent inclure un système de suivi des bogues. Nous utilisons Jira et marquons tous les commentaires avec l'ID de numéro de Jira. Aucune autre intégration n'est mise en œuvre en ce moment.
Il est possible que la solution ait un meilleur processus. Mais s'il y a des outils pour soutenir ce processus de meilleur processus, j'aimerais apprendre sur leur existence, ou le moyen de les utiliser.
8 Réponses :
À partir de la version 1.5, SVN met des informations sur les révisions fusionnées dans les propriétés. Vous devriez être capable de le trouver là et de le faire sentir. Toutefois, cela ne vous dit que quelles révisions étaient fusionnées, non pas lesquelles des révisions ont été oubliées de fusionner.
À la fin, je suppose que tout se résume à ceux qui font une solution sur une branche étant également responsable de la fusionner dans le coffre. La meilleure façon de s'assurer que cela se produit probablement est la pression des pairs. :)
En fin de compte, je suppose que tout se résume à ceux qui font un correctif sur une branche étant également responsable de la fusionner dans le coffre. La meilleure façon de s'assurer que cela se produit probablement est la pression des pairs. :) [2]
Les versions plus récentes de Subversion (je pense, à partir de 1,5 ou 1.6) ont un suivi de fusion. C'est-à-dire que la subversion continue de suivre laquelle des modifications apportées à la branche a été fusionnée au coffre.
Vous pouvez fusionner toutes les modifications de la branche au coffre à l'aide de la commande: P>
svn co https://server/repo/trunk cd trunk svn merge --reintegrate https://server/repo/branches/branch_name <check merge results, run unit tests, etc> svn commit
Premièrement, le moyen d'être sûr que ces choses sont faites consiste à enregistrer la vérification du correctif sur la branche de la version et à la vérification de la fusion au coffre dans l'entrée de votre bogue dans votre système de suivi de bogues. Si vous n'avez pas de système de suivi de bugs, obtenez-en un. En plus d'aider avec les correctifs de suivi, il résout de nombreux autres problèmes qui suivent le suivi de l'état des bugs.
Deuxièmement, vous voudrez peut-être envisager une approche alternative. Lorsque vous dupliquez un bug dans une version libérée, essayez-la de la dupliquer également dans la tête du coffre. La plupart du temps, vous trouverez que cela se produit toujours. Fixez-le dans le coffre et vérifiez que résoudre ce problème. Ensuite, fusionnez ensuite le changement dans les branches pour des versions déjà libérées qui nécessitent le correctif (vous devrez peut-être modifier le correctif pour tenir compte de l'environnement différent). Si le bogue se produit uniquement dans une branche de libération, il y a réparer là-bas (il n'a pas besoin d'être fusionné dans le coffre).
Si vos bugs sont dans un suivi de bug (et ils devraient être), vous pouvez l'utiliser pour suivre ceci. Il devrait y avoir une manière dans votre suivi de votre bogue pour marquer quelles versions sont affectées.
Pour vous assurer qu'un bug fermé est réellement résolu, les personnes QA / Testing devraient Test que le bogue est en réalité fixe dans tous les versions pris en charge.
Le suivi de la fusion de SVN peut aider certains, mais il ne peut finalement pas vous dire:
Le test est vraiment le meilleur moyen d'être sûr qu'un bogue est parti. Si vous n'avez pas de personnes QA / Test, vous pouvez avoir un développeur différent, faites-le ou embaucher des testeurs de logiciels.
Il n'y a rien dans SVN pour vous dire quel code vous devriez ou ne devrait pas vérifier, brancher, fusionner ou supprimer. Ce n'est pas son travail. Il convient parfaitement à son travail - ce qui vous fournit un outil VERHED pour stocker votre code dans.
Donc, vous n'avez pas besoin d'un outil pour gérer votre code mieux, vous avez besoin d'un système externe pour mieux gérer vos développeurs :)
Une manière est une solution, un test et un suivi de bugs - comme des changements de code sont effectués, le fait que quelque chose a été effectué au code est enregistré et suivi à travers les différentes phases. Vous ne voulez généralement pas que quiconque apporte des modifications au code sans une raison quelconque (autre que «j'ai eu besoin de refactoring»), donc un outil de suivi est une bonne idée de toute façon. Les bugs étant fixés en une seule version, cet outil peut être utilisé pour vous assurer que le bogue est également corrigé dans les autres (le cas échéant - parfois, vous ne voulez pas un changement particulier apporté à une version)
SVN peut s'intégrer à ces outils, par exemple, mon repo met à jour mon bugtracker de Mantis lorsque certains mots magiques sont ajoutés à un checkin (si vous tapez "MANIS fixe # 1234" dans le commentaire CheckIn, MANIS Bug 1234 sera mis à jour avec Les fichiers modifiés et son statut changé en "test en attente")
alternativement des outils tels que ReviewBoard peut également s'intégrer, comme vous effectuez une modification, la révision peut être postée là-bas pour que d'autres personnes à signer, le processus de désactivation peut inclure en veillant à ce que le bogue soit fusionné ou qu'un nouveau rapport de bogue est créé pour le autres versions que vous avez besoin de la réparer aussi.
Donc, le problème n'est pas avec SVN ici, c'est avec vos processus de développement.
Bonne réponse. Bien qu'un peu trop du côté théorique, et moins sur le point pratique. Je n'ai pas dit que je veux que Svn résoudra mon problème. J'ai dit que je cherche une solution. Votre réponse me pointe dans une bonne direction. Mais j'espérais avoir quelque chose de plus concret. Peut-être que cette réponse magique n'existe pas, et j'ai juste besoin de travailler sur notre processus. Nous utilisons Jira comme suivi de bugs, mais il n'est pas directement intégré à SVN pour le moment. Nous ajoutons l'identifiant de la question de Jira sur chaque commit SVN.
Principalement théorique parce que je ne connais pas assez de vos processus. Par exemple, si vous avez trouvé SVN à Jira, vous pouvez au moins voir dans les notes de bugs quels fichiers ont été modifiés et qui est responsable de la fermeture du bogue (veuillez ne pas dire que son développeur) serait alors capable de voir que Seule la branche a été fixée et pourrait le garder ouvert jusqu'à ce que le tronc ou d'autres branches aient également le correctif.
Vous voudrez peut-être adapter les développeurs Strateversion Subversion utiliser eux-mêmes: faire la majeure partie du développement dans le coffre, libérer des branches. Lorsqu'un bogue est trouvé, il est d'abord fixé dans le coffre, puis le correctif est fusionné du coffre à la branche.
La fusion du coffre à une branche de la version est plus difficile et plus risquée.
Voici ce que nous faisons, je viens blogué à ce sujet - Nous configurons une construction spéciale dans notre serveur CI qui s'assure, la nuit, qu'aucun changement non différencié n'existe.
J'ai écrit un script un peu de temps à faire exactement cela. Nous avons eu un certain nombre de branches simultanées sur un projet que je travaillais, et il était très difficile de garder une trace de tous les engagements et de la fusion.
Vous pouvez trouver le script à: Disons que vous avez un 2.0 branche de libération. Pour découvrir tout ce qui est commis dans 2.0, qui n'a pas encore été fusionné au coffre: Cela produira quelque chose comme: