Flux de travail Mercurial avec branches stables et par défaut

Question

Nous essayons de migrer de Subversion vers Mercurial mais nous rencontrons quelques problèmes. Tout d'abord un peu de fond:

flux désiré:

Nous aimerions avoir que deux branches nommées, stable et par défaut, dans un référentiel.

• Le développement a lieu sur la branche par défaut.
• Les corrections de bogues sont validées par une branche stable et fusionnées par défaut.
• Après chaque Sprint, nous marquons notre branche par défaut. Finalement, nous pouvons publier une nouvelle version, pour laquelle nous apportons du code (peut-être la dernière balise Sprint) de la valeur par défaut à stable (, merge Sprint_xyz), marquer la branche (tag Release_xyz) et publier.

Nous voulons aussi les emplois suivants sur notre serveur construire Jenkins pour CI:

• fin de Sprint emploi: Ce travail devrait marquer par défaut avec quelque chose comme Sprint_xyz
• Libérez le travail: Ce travail doit apporter les dernières modifications de tag "Sprint" à la branche stable, puis étiqueter stable avec quelque chose comme Release_6.0.0 et créer une version.

Un peu plus fond:

Mercurial est nouveau pour nous, mais pour ce que nous avons vu, cela semble être une approche saine d'esprit. Nous avons choisi des balises pour marquer les versions sur les branches nommées et les branches clonées en essayant de rendre le flux de travail de développement aussi simple que possible (une seule étape de fusion, un seul contrôle, seulement quelques branches à suivre ...). Nous utilisons la mêlée et potentiellement (mais pas nécessairement) une version après chaque sprint qui peut (ou pas) devenir une partie de la branche stable et devenir une version "livrable".

Le problème que nous rencontrons (et qui nous fait nous demander si nous approchons de la bonne façon ...) Est la suivante:

Nous travaillons sur la branche par défaut (« d » sur les pauvres man 'graphe qui suit):

d -o-o-o-o- 

Nous terminons un sprint et déclencher une fin de Sprint emploi (en utilisant Jenkins) qui balises par défaut avec "Sprint 1":

d -o-o-o-o-o- 
      | 
     Sprint 1 

pour libérer Sprint 1, nous mettons à jour la branche stable ('s') et fusionner les changements de la révision de l'étiquette Sprint 1 et commettons:

  Sprint 1 
      | 
d -o-o-o-o-o- 
      \ 
s -o-o-o-o-o-o- 

Tag stable et commit:

  Sprint 1 
      | 
d -o-o-o-o-o- 
      \ 
s -o-o-o-o-o-o-o- 
       | 
      Release 1 

mise à jour par défaut et la fusion stable depuis le défaut devrait rester stable surensemble, engager et pousser:

 Sprint 1 
      | 
d -o-o-o-o-o-o-o-o-o- 
      \ /
s -o-o-o-o-o-o-o- 
       | 
      Release 1 

Le problème est que lors de la fusion de .hgtags 's' à 'd' mercurial rencontre un conflit qui empêche le travail de libération de se terminer. Les .hgtags résultants devraient contenir des informations des deux balises impliquées. Nous avons cherché une solution à cela, et nous pourrions probablement automatiser ce type de conflits de fusion avec certains hooks et scripts, mais cela ressemble à un hack inutile et sujet aux erreurs pour supporter un workflow qui ne semble pas sortir de l'ordinaire.

1. Y a-t-il quelque chose de fondamentalement mauvais dans notre approche qui nous amène à rencontrer ces problèmes? Si ce n'est pas le cas, quelle est la meilleure façon de résoudre ces problèmes sans avoir recours à une approche scripts/hooks?
2. Y a-t-il une meilleure approche qui soutiendrait notre flux de travail?

Answer 1

Je voudrais aller pour les crochets cas spéciaux. Le problème que vous voyez est lié à la philosophie Mercurial des métadonnées de versionnement de la même manière que les données de référentiel normales. C'est simple et efficace, et conduit à un système qui est globalement plus facile à comprendre. Mais dans ce cas, cela conduit également à votre conflit de fusion.

La raison pour laquelle cela conduit à un conflit de fusion est relativement simple. Le fichier .hgtags est juste un fichier texte avec un tas de lignes dedans. Chaque ligne contient un hachage et la balise associée. Dans une branche, vous avez ajouté la balise Sprint 1. Dans une autre branche, vous avez ajouté la balise Release 1. Elles apparaissent lorsqu'une ligne est ajoutée à la fin du fichier dans une branche et qu'une ligne différente est ajoutée à la fin du fichier dans une autre branche.

Ensuite, vous fusionnez les deux branches. Soudain, Mercurial est confronté à une décision. Quelle ligne devrait-il prendre? Devrait-il prendre les deux? Si c'était le code source, il n'y aurait vraiment aucun moyen de le dire sans intervention humaine.

Mais ce n'est pas un code source. C'est un tas de tags. La règle devrait être "si les deux lignes ajoutées se réfèrent à des étiquettes différentes, prenez les deux". Mais ce n'est pas parce que Mercurial le traite comme un fichier texte standard qui pourrait être un code source important.

Vraiment, le fichier .hgtags devrait être traité d'une manière assez spéciale pour les fusions. Et il pourrait être bon d'ajouter du code qui le gère de cette façon dans la ligne principale Mercurial pour supporter votre cas d'utilisation.

IMHO Mercurial devrait être modifié afin que le fichier .hgtags ne vous donne un avertissement de conflit que si vous avez deux hashes différents pour le même tag. L'autre cas bizarre serait si vous avez une étiquette avec un hachage qui n'est pas un ancêtre du changement dans lequel la balise apparaît. Ce cas devrait être appelé d'une manière ou d'une autre lors d'une fusion, mais ce n'est pas vraiment un conflit.

Answer 2

Je suppose que vous fusionnez le jeu de modifications marqué par défaut à stable. Si vous fusionnez le tagging changeset à la place, vous ne devriez pas obtenir le conflit de fusion lorsque vous fusionnez le second changeset (probablement aussi tagging!) Changeset à défaut.