Comment puis-je travailler simultanément sur la version 1.1 et la version 2.0?

Question

La situation: Nous ne sommes plus en version bêta et la version 1.0 a été publiée sur plusieurs sites clients. L'équipe A est déjà occupée à travailler sur la version 1.1 qui comportera des corrections de bogues incrémentielles et des ajustements de convivialité, tandis qu'une autre équipe travaille sur la version 2.0 avec des changements à grande échelle, où le noyau du produit pourrait avoir été complètement repensé. Maintenant, la plupart des changements faits pour 1.1 devront se faire dans la version 2.0 à un moment donné, et certaines corrections de bogues faites dans la branche 2.0 pourraient en fait être planifiées pour une version antérieure. Le problème est que puisque 2.0 a des différences fondamentales, aucun changement de 1.1 ne peut être fusionné sans conversion manuelle, et vice versa.

Ma question: Quelles sont les meilleures pratiques de contrôle de révision pour minimiser les conflits de fusion et le travail en double dans ce genre de situation? Comment puis-je m'assurer que mes équipes passent le moins de temps et d'effort possible sur les problèmes de contrôle des révisions, tout en fournissant des correctifs réguliers aux clients?

Answer 1

Un bon moyen est de corriger chaque bogue dans la branche stable et de fusionner la branche stable dans la branche de développement. C'est le modèle Parallel Maintenance/Development Lines, et la clé est de fusionner tôt et souvent. La fusion peu fréquente et tardive signifie que la branche de développement est méconnaissable par rapport à la branche stable, ou que le bug ne peut pas être répété de la même manière.

Subversion inclut le suivi de fusion depuis la version 1.5 afin que vous vous assuriez que le même ensemble de modifications n'est pas fusionné deux fois, ce qui provoque des conflits idiots. D'autres systèmes existent (par exemple Git, Mercurial, Accurev, Perforce) qui vous permettent de faire des requêtes du type "quels changements sur la branche A n'ont pas été fusionnés dans la branche B?" et choisissez les correctifs dont vous avez besoin dans la branche dev.

Answer 2

Je me fierais probablement à un système de suivi des problèmes à cette fin, et je m'assurerais de marquer chaque changement qui devait être apporté dans le code de ligne. Vous pouvez ensuite vous assurer que les commentaires d'archivage pour chaque modification référencent le problème pertinent et expriment clairement l'intention du changement de code afin qu'il puisse être facilement compris lorsque vous tentez de le réimplémenter dans le coffre.

Answer 3

L'article here (au jour le jour avec Subversion) mentionne qu'une méthode consiste à mettre constamment à jour la version 2 avec des données de la version 1.1. Dans l'article, le gars dit de le faire tous les jours.

La partie que vous voulez lire est intitulée "Serveur, il y a un bug dans mon coffre!". C'est à peu près à mi-chemin de l'article.

Answer 4

Fusionnez tôt, fusionnez souvent et assurez-vous que le contrôle qualité sur la ligne principale connaît et régresse/vérifie les défauts résolus dans chaque correctif des versions de maintenance. Il est vraiment facile de laisser filer quelque chose et de "désamorcer" un bug dans une version ultérieure, et laissez-moi vous dire que les clients ne se soucient pas de la complexité de gérer plusieurs branches - c'est votre travail. Assurez-vous que vous utilisez un système de contrôle de source qui prend en charge le branchement et la fusion (j'ai eu de l'expérience avec Perforce et SVN, et bien que Perforce soit meilleur, le SVN est gratuit). Je crois également que le fait d'avoir une seule personne responsable de la réalisation des fusions de manière cohérente permet de s'assurer qu'ils se produisent régulièrement. C'est généralement moi ou l'une des personnes les plus expérimentées de notre équipe.

Answer 5

La façon dont nous traitons cela à mon travail est de garder la branche du tronc comme le code le plus à la pointe (c.-à-d. 2,0 dans ce cas). Vous créez une branche pour le code 1.x, et y faites toutes vos corrections. Toute modification apportée à 1.x doit être fusionnée (manuellement si nécessaire) dans la branche trunk (2.0).Je voudrais alors insister pour que les développeurs 1.x prennent note à la fois du numéro de révision pour la validation 1.x et du numéro de révision pour la fusion 2.0 dans le ticket pour ce bogue. De cette façon, il sera plus facile de remarquer si quelqu'un oublie de fusionner ses changements, et le fait qu'ils doivent garder une trace de cela les aidera à se souvenir.

Answer 6

Quasiment ce que tout le monde l'a dit, mais je pensais que je lancer dans mon expérience avec le développement de manutention dans plusieurs branches en utilisant SVN

Avec notre produit principal, nous avons la nécessité de développer simultanément dans les versions à 2 + le même temps.

À l'origine, j'utilisais le tronc principal comme version «développement principal», avec des étiquettes utilisées pour chaque version réelle. Les branches ont été utilisées pour des efforts de développement importants pour un nouvel ensemble de fonctionnalités. Puis, plus tard, lorsque nous avons commencé à travailler sur les versions 2, 3 et 4 à la fois, j'ai commencé à utiliser une branche pour chaque révision. Étant donné que je gère le référentiel et que je gère également les builds QA, je m'assure de faire des "rollups" chaque matin - ce qui consiste à fusionner les modifications dans l'arborescence en commençant par la branche actuellement active la plus basse. Alors je finis par la fusion des changements de 1,1 à 1,2, ce qui est fusionné en 1.3 avec tout autre changement de 1,2 depuis la dernière fusion, etc.

Quand je commets, je fais que commenter toujours la validation avec quelque chose comme

fusionné 1.1 rev 5656-5690

il peut être un peu d'une douleur, mais il fonctionne :)

Answer 7

un point clé est capturé dans this picture de BUILD Doctor: seulement fusionner une direction .

Answer 8

Pour répondre à cette question, de nombreux développeurs sont passés de Subversion à Git. Commander github.com.