Comment inverser l'effet d'une fusion sur des branches polarisées sans mourir d'agonie ?
Ce problème me tourmente depuis mois et j'ai finalement abandonné.
Vous avez 1 référentiel, avec 2 Nommé Branches. A et B.
Les changements qui surviennent en A se répercutent inévitablement en B.
Les changements qui se produisent directement sur B NE DOIVENT JAMAIS se produire sur A.
Dans une telle configuration, la fusion de "B" en "A" produit un gros problème dans le référentiel, car toutes les modifications de B apparaissent dans A comme si elles avaient été faites dans A.
La seule façon "normale" de se remettre de cette situation semble être de "revenir en arrière" dans la fusion, c'est-à-dire d'annuler la fusion :
hg up -r A
hg backout -r BadMergeRev --parent BadMergerevBeforeOnA Ce qui semble très bien, jusqu'à ce que vous décidiez de fusionner plus tard dans la bonne direction, et vous vous retrouvez avec toutes sortes de choses désagréables qui se produisent et le code qui a été effacé / commenté sur la branche spécifique B devient soudainement non effacé ou non commenté.
Jusqu'à présent, il n'y a pas eu de solution viable à ce problème, à part "laisser faire les choses, puis régler tous les problèmes à la main", ce qui, pour être honnête, est un peu foireux.
Voici une image qui clarifie le problème :
[Image originale perdue]
Les fichiers C et E (ou les modifications C et E) doivent apparaître uniquement sur la branche b, et non sur la branche a. La révision A9 ici ( branche a, revno 9 ) est le début du problème.
Les révisions A10 et A11 sont les phases de "fusion du backout" et de "fusion du backout".
Et la révision B12 est mercuriale, abandonnant par erreur et à plusieurs reprises un changement qui ne devait pas être abandonné.
Ce dilemme a causé beaucoup de frustration et de fumée bleue et je voudrais y mettre un terme.
Note
La réponse la plus évidente est peut-être d'essayer d'empêcher la fusion inverse de se produire, soit avec des crochets, soit avec des politiques, mais j'ai constaté que la capacité de faire échouer cette opération est plutôt élevée et que le risque qu'elle se produise est si probable que, même avec des contre-mesures, on ne peut pas faire autrement. doit suppose toujours qu'inévitablement, il sera pour que vous puissiez le résoudre quand il se produira.
Elaborer
Dans le modèle, j'ai utilisé des fichiers séparés. Ceux-ci font paraître le problème simple. Ils représentent simplement changements arbitraires qui pourrait être une ligne séparée.
De plus, pour ajouter l'insulte à l'injure, des modifications substantielles ont été apportées à la branche A, ce qui pose le problème suivant : "les modifications de la branche A entrent-elles en conflit avec les modifications de la branche B qui viennent d'apparaître (et qui ont été retirées) et qui ressemblent à une modification de la branche A ?
Sur les astuces de réécriture de l'histoire :
Le problème de toutes ces solutions rétroactives est le suivant :
- Nous avons 9000 commits.
- Le clonage à l'état frais prend donc une demi-heure
- S'il existe même un mauvais clone du référentiel quelque part il est probable qu'il revienne en contact avec le dépôt d'origine, et le perturbe à nouveau.
- Tout le monde a déjà cloné ce dépôt, et maintenant plusieurs jours ont passé avec des commits continus.
- L'un de ces clones se trouve être un site actif, donc "effacer ce site et repartir de zéro" = "grand nono".
(J'admets que la plupart des propositions ci-dessus sont un peu stupides, mais elles sont hors de mon contrôle).
Les seules solutions qui sont viables sont celles qui supposent que les gens peut et sera font tout de travers, et qu'il existe un moyen de "défaire" ces erreurs.
