MQ contresuccursales à Mercurial

Question

Je travaille avec Mercurial depuis un certain temps maintenant.Lorsque j'apportais des modifications (privées) à certains logiciels tiers, dans le passé, je créais toujours une branche nommée distincte pour ces modifications.Lorsque le code en amont est mis à jour, je le fusionne simplement dans ma branche nommée.

Aujourd'hui, j'ai lu sur MQ (Mercurial Queues - chapitres 12 et 13).Je pense avoir compris le concept derrière MQ, donc ma question est la suivante :

Y a-t-il un avantage de MQ par rapport aux branches (nommées) dans Mercurial (pour mon scénario) ?

Answer 1

Les principaux avantages de MQ par rapport aux branches nommées sont :

• Vous pouvez réviser vos correctifs.Cela vous permet de modifier l'historique et ainsi de conserver une série de correctifs propres et logiques au-dessus du code en amont :si vous remarquez une erreur dans un patch, vous actualisez le patch au lieu de faire un nouveau commit.

• Les modifications apportées à vos patchs seront clairement séparées des modifications apportées en amont.Lorsque vous fusionnez deux branches, vous mélangez les deux flux de développement.Cela rend difficile la visualisation des modifications que vous avez apportées sans également voir les modifications provenant de la branche en amont.

• Les noms de patch sont transitoires.Lorsque vous hg qfinish un patch appliqué, il n'y a aucune trace du nom du patch dans la validation.Vous pouvez donc utiliser MQ sans vous coordonner au préalable avec le référentiel en amont, car ils ne remarqueront jamais MQ.

• Vous évitez les fusions.Au lieu de fusionner avec le dernier code en amont, vous rebase vos correctifs appliqués.Cela vous donne un historique plus simple.L'historique est évidemment faux puisque vous prétendez avoir réalisé tous vos patchs après voir le code depuis l'amont - alors qu'en fait vous l'avez créé en parallèle avec l'amont et plus tard déplacé vos patchs à la pointe de l'amont.

• Vous n'avez pas de nom de branche permanent dans les ensembles de modifications.Les gens parfois traiter les branches nommées comme jetables et s'énervent lorsqu'ils se rendent compte qu'une branche nommée est fixée dans l'histoire.(Vous pouvez en fait définir le nom de la branche avec hg branch avant de pousser les patchs donc ce point n'est pas si grave.)

Les inconvénients de MQ sont :

• C'est un outil supplémentaire pour apprendre.C'est puissant, mais cela vous donne aussi plus de possibilités de vous tirer une balle dans le pied.En cours d'exécution hg qdelete va vraiment supprimer le patch et ainsi vous pouvez jeter les données.(Je pense que c'est bien, mais un utilisateur de Git est venu sur notre liste de diffusion pour s'en plaindre.)

• Vous rendez beaucoup plus difficile la collaboration avec les autres.Toi peut tourner .hg/patches dans un référentiel et push/pull des correctifs entre les référentiels, mais c'est difficile à faire si vous êtes plus d'un seul développeur.Le problème est que vous finissez par fusionner les correctifs si plusieurs personnes actualisent le même correctif.

• Vous n'avez pas de nom de branche permanent dans les ensembles de modifications.Si vous utilisez correctement les branches nommées et utilisez des noms de branche stables et à long terme, cela vous manquera lors de l'utilisation de MQ.

Answer 2

bonne question.Ça dépend.Personnellement, je n'aime pas le système de branchement mercurial, et j'essaie de l'éviter quand je peux (utiliser des signets poussés au lieu de la branche).

MQ est un excellent outil, avec une grande puissance et de grands pièges.Vous pouvez également envisager d'utiliser pbranch .

MQ est un excellent outil si vous devez produire et maintenir un jeu de patch pour un projet, comme l'ajout de fonctionnalité-X à un projet et de maintenir les correctifs mis à jour avec le code en amont.

Les signets (ou les succursales si vous aimez) sont bons pour une tâche de développement à court terme qui doivent être fusionnées dans le code en amont.