dépôt d'équipe mercurial/cueillette et le choix

Question

J'ai une petite équipe et je voudrais faire ce qui suit:

Je me trompe, je vais l'appeler COFFRE

Maintenant, COFFRE est un projet c'est déjà en production et en cours d'exécution. Maintenant, les défauts inévitables entrent, mais dans Bugzilla et sont assignés aux utilisateurs.

Chaque clones utilisateur COFFRE à leurs dépôts et fait les changements et les pousse à un trunk/projets de répertoire (projets ne sont pas un clone de COFFRE, juste un répertoire régulier)

Maintenant, vient le jour où je veux pour créer une nouvelle version appelée RELEASE et je veux fusionner certaines des corrections de bugs (pas toutes, juste quelques unes) dans RELEASE.

Notez, je ne suis pas engagé à l'idée d'avoir TRUNK/projects/[liste de corrections de bugs], mais c'est ce que j'ai actuellement et je suis plus qu'ouvert à toutes les suggestions.

Quelles sont quelques idées? Y at-il quelque chose que je peux faire/que je devrais faire différemment? Encore une fois, je suis ouvert à toutes/toutes les suggestions, y compris en changeant complètement la procédure ci-dessus (sauf pour utiliser Mercurial car c'est ce que l'entreprise nous fait utiliser)

Answer 1

Il y a deux façons de le faire et ils ne divergent pas au moment de la publication, mais lorsque vous effectuez les corrections de bogues en fonction du parent que vous donnez les changesets de correction de bugs. Le "bon" moyen utilise seulement pousser, tirer, et fusionner. Le moins bon moyen (ce n'est pas tout à fait mauvais, mais c'est certainement sous-optimal) est appelé cherry picking et il a des inconvénients. La partie la plus difficile est de savoir si vous allez être capable de déplacer des corrections de bugs dans RELEASE via la fusion sans déplacer tout ce qui est de TRUNK vers RELEASE est quelque chose que vous devez décider avant d'apporter cette modification.

est ici une réponse vraiment complète pour une question similaire qui explique ce qui se passe: Some help with merging legacy branch in Mercurial

Le concept clé cependant, est que vous pouvez fusionner un changeset dans une branche que vous voulez mais il apporte avec lui tous ses changesets ancêtres. Donc vous voulez que votre bug soit corrigé pour avoir ascendance minimale. Cela signifie que vous ne devez pas corriger un bug dans un nouveau changeset dans TRUNK qui est la dernière fonctionnalité que vous avez ajoutée, mais plutôt, d'abord, un changement qui existe déjà dans votre TRUNK et votre RELEASE, et il y a deux excellents candidats pour cette.Soit:

• où le changeset RELEASE et COFFRE divergé

ou

• où le changeset le bug a été introduit

Ma préférence est pour la suite. Si un bug a été introduit dans changeset 666 alors chaque clone, branche, et build qui a changes6 666 voudront votre correctif. Ainsi, lors de la fixation faites juste:

hg update 666 
    .. fix the bug .. 
    hg commit -m "fixed bug 55" # creats changeset 999 which a new head 

Ensuite, vous pouvez faire ceci:

hg update TRUNK 
hg merge 999 

et vous saurez que vous ne tirer dans une seule changeset. Plus tard, quand vous êtes prêt à libérer que vous pouvez faire:

hg update RELEASE 
hg merge 999 

et vous êtes à nouveau en obtenant seulement le single changeset que vous voulez. L'avantage de ce mode de travail sur cherrypicking (en utilisant l'exportation/importation ou la transplantation) est que votre solution n'existe qu'une seule fois dans votre repo. Si vous avez 99 différentes branches de fournisseurs pour divers clients pointilleux et que vous voulez voir s'ils ont le correctif pour le bogue 55 vous pouvez simplement faire:

hg log -r 'descendants(999) and heads(FUSSYCUSTOMERBRANCHNAME)' 

et s'il n'y a pas de résultats alors que le client ne dispose pas 999 et n'a donc pas le correctif pour le bug 55 dans changeset 666. Lorsque vous refaire le même travail avec plusieurs changesets (qui est le résultat de l'exportation/importation et la transplantation), il est plus difficile à vérifier.

Answer 2

La pratique courante est de créer des branches thématiques. Chaque nouvelle émission/ticket/amélioration est enregistrée dans une branche distincte.

Chaque mainteneur veut faire une nouvelle version, il peut fusionner tous (ou seulement certains) qui se branche en "par défaut" ou même une nouvelle branche appelée par ex. "release_1_x".

Pour être plus précis. Le développeur travaillant sur le code peut toujours cloner le référentiel, puis créer une branche locale et enfin, après qu'un ou plusieurs commits à cette branche, pousse les changements locaux à un clone centralisé (à partir duquel tous les autres développeurs de l'équipe peuvent tirer/cloner à nouveau).