Contrairement à ce que l'on pourrait penser a priori, il y a un bon et un mauvais sens pour fusionner deux têtes dans en entrepôt mercurial. Prenons un exemple et admettons que l'on parte d'une révision 123. Alfred, Barnabé et Coruscant font des changements qui produisent l'arbre suivant:
123 -> 124 -> 125 ---> 126 -> 129 --> 130
\-> 127 -> 128 /
Si dans le même temps, Zoé part de la révision 123 et produit l'arbre: 123 -> 131 quand Zoé va vouloir faire son hg push sur l'entrepôt partagé, elle va avoir le message "ça crée des têtes, est-ce que vous êtes sûr de vouloir faire ce push". Zoé va se dire qu'il vaut mieux commencer par un 'pull' et un 'merge', mais c'est là qu'il faut se méfier. En effet, si Zoé est sur la révision 131 et qu'elle fusionne avec 130, le changeset sera énorme car il contiendra tous les changements qui permettent de passer de 123 à 130. En revanche, si Zoé passe sur la 130 et fusionne avec la 131, elle n'aura que les changements qu'elle vient d'apporter. Dans le premier cas, le 'merge' sera difficile à comprendre, alors qu'il sera bien plus simple dans le second. Au final, comment faire la fusion dans le "bon" sens ? 1/ hg push -> ah tient, ça crée des têtes, donc je ne le fais pas 2/ hg pull -u ou hg pull suivi de hg merge -> y'a eu un merge 3/ hg status -> beaucoup de fichiers modifiés... oulàlà, c'est bizarre je vais regarder 4/ hgview -> ah oui, sur l'autre tête y'a beaucoup plus de changements, donc je vais plutôt faire le 'merge' dans l'autre sens 5/ hg up -C ab123_autre_tete -> je me retrouve sur l'autre tête 6/ hg merge cd456_ma_tete -> un joli 'merge' 7/ hg status -> seulement quelques fichiers modifés, voilà qui est mieux 8/ hg ci -m merge -> youpi, je valide cette fusion 9/ hg push -> tagada, je partage avec mes voisins Moralité: faites des hg status et des hgview aussi souvent que nécessaire pour préparer vos commits et parvenir à un historique facile à comprendre. Remarque: on peut aussi remplacer les étapes 5, 6 et 7 par hg diff -r ab123_autre_tete -r cd456_ma_tete pour afficher le diff de ma_tete par rapport à autre_tete, car l'opération de fusion doit être symétrique et donner le même résultat qu'on la lance depuis l'une ou l'autre tête, même si l'affichage par défaut de hg status et hg diff dépend de la tête qui constitue le premier parent (l'étape 5 ayant justement pour effet de changer ce premier parent). |


Semantic Roundup - infos glanées au NextMediaCamp

Comments
-
2008/12/23 02:01, written by laubry
| reply to this comment
-
2009/08/25 13:02, written by anon
| reply to this comment
(add comment)non, hgview est buggé sur les diffs de merge, dans un sens ou l'autre un merge pour mercurial c'est exactement la même chose (du moins je l'espère).
Le diff d'un merge c'est normalement la différence entre le merge auto et le résultat (ie la résolution de conflit)
le diff a pas la même tête, en fonction du sens