Workflow Mercurial pour environ 15 développeurs - Devrions-nous utiliser des branches nommées?

Question

Mon équipe commence tout juste avec la Mercurial, et d'un référentiel central. Nous avons Hudson bâtiment à la pointe de la branche par défaut - qui est en fait notre réseau principal. Nous avons eu une politique d'enregistrement avec nos vieux VCS que des revues de code, les tests, etc. doit être fait avant de vous enregistrer à la canalisation principale.

Donc, disons que vous travaillez sur la fonctionnalité X. Vous travaillez sur des choses qui, en le fondant de "par défaut", puis vous vous engagez partielle d'une fonction comme un point de contrôle. Localement votre "défaut" est maintenant cassé -- vous n'avez pas partagé avec quelqu'un, mais si vous décidez de faire un push, et bien maintenant vous avez cassé le code dans la canalisation principale.

Même si vous vous attendez à pousser jusqu'à ce que vous l'avez tous triés, il semble comme il y a des situations (par exemple, de travailler sur deux choses à la fois) où vous auriez besoin de pousser certaines modifications, mais pas tous.

En outre, si vous signez tous vos changements de point de contrôle, puis il y aura des révisions dans la canalisation principale qui construisent, et d'autres dans la canalisation principale que de ne pas construire.

Nous avons commencé à utiliser les branches nommées, mais plus de la lecture, je ne le plus je pense que nous sommes mal à l'aide de branches nommées.

Toutes les suggestions sur la façon de configurer un bon flux de travail qui nous permet d'exécuter d'Hudson et de garder notre ligne principale de la politique?

Answer 1

Tout d'abord, je vous recommande fortement d'Un Guide de branchement dans les Mercurial

Ensuite, vous pouvez appuyez simplement sur la branche courante: coup de pouce - Une Version plus Douce de Pousser

Et peut-être que vous pourriez décider d'autoriser uniquement la tête et par branche: 32. Prévenir une poussée qui permettrait de créer plusieurs têtes

D'autres, DONC les questions liées aux branches nommées:

• Mercurial: les Branches Nommées vs Plusieurs Référentiels
• Dépôt Mercurial disposition pour de multiples branches

Answer 2

Vous pourriez envisager au moins deux référentiels. Les "principales" référentiel a vos testé et révisé de code. Le Code n'est poussé à ce dépôt après Hudson a testé et après quelles que soient les critiques que vous avez terminé. Le "test" référentiel serait un clone de la canalisation principale. C'est le référentiel d'Hudson moniteurs, de sorte que si un ensemble de modifications est poussé vers le dépôt de test, Hudson tests est. Vous pouvez mettre en place un Hudson étape de génération qui pousse les modifications à partir du dépôt de test de votre ligne principale si les tests passent.

Les développeurs de toujours pousser pour le dépôt de test, mais seulement tirer à partir de la ligne principale, de sorte qu'ils ne jamais tirer dans le code à tester. Si elles ont besoin de partager non testé les révisions, ils pourraient pousser/tirer directement entre les uns des autres espaces de stockage locaux. Peut-être qu'il est possible de configurer Hg, de sorte que la canalisation principale accepte uniquement les pousse à partir du dépôt de test, de sorte que les développeurs ne peuvent pas accidentellement pousser à la canalisation principale au lieu de tester.

Il pourrait être bon d'avoir un examen de référentiel. Afin de pousser les développeurs à tester, Hudson pousse code testé à l'examen, et à la revue de code est poussé à la canalisation principale.

Avertissement: je n'ai utilisé Hg sur trivial projets et de piètres moyens.

Answer 3

Ce que nous faisons dans mon entreprise, est d'utiliser une branche nommée pour la distinguer de la version stable (sur lequel nous n'engageons que des corrections de bug) et la prochaine version à laquelle le développement se produit et nous backport correctifs de stable à défaut sur une base régulière (avec hg merge stable sur la branche par défaut).

Pour l'examen du code, nous utilisons la mq extension pour permettre aux développeurs de soumettre des rustines. Et les développeurs peuvent tirer des uns et des autres dépôts, sans polluer le référentiel.

Avertissement : nous n'utilisons pas d'Hudson.

Answer 4

C'est une question d'état d'esprit. L'distribué VCSes ne pas vous obliger à garder un seul référentiel central.

Plutôt que d'avoir de la canalisation principale ouvert à tous pour vérifier sur, mis en place avec la limitation des accès en écriture. Seules les modifications qui ont été approuvées (testé, signé, tout ce qui fait sens pour vous) sont incorporés dans la canalisation principale.

La façon dont vous parvenez à obtenir des changements dans la canalisation principale est alors grande ouverte la question avec plusieurs réponses possibles. Voici deux sur le dessus de ma tête:

• Les développeurs pourraient pousser librement à une centrale de "test" repo, à partir de laquelle les modifications sont examinées.
• Les développeurs de publier des révisions sur leurs propres postes de travail (rappelez-vous, les branches à bas prix) et le réseau principal au processus d'examen ramasser directement à partir de là.

Answer 5

Vous pouvez également envisager d'utiliser l'extension Signets au lieu de branches nommées.

Si vous connaissez git, les signets se comportent comme des branches git au lieu des branches mercurielles.