Dans un VCS traditionnel, je peux comprendre pourquoi vous ne valideriez pas les fichiers non résolus car vous pourriez casser la construction. Cependant, je ne comprends pas pourquoi vous ne devriez pas valider des fichiers non résolus dans un DVCS (certains d'entre eux vous empêcheront en fait de valider les fichiers).
Au lieu de cela, je pense que votre référentiel doit être verrouillé contre les poussées et les tirages , mais pas dans la validation.
La possibilité de s'engager pendant le processus de fusion présente plusieurs avantages (comme je le vois):
- Les changements de fusion réels sont dans l'histoire.
- Si la fusion était très importante, vous pouvez effectuer des validations périodiques.
- Si vous avez fait une erreur, il serait beaucoup plus facile de revenir en arrière (sans avoir à refaire toute la fusion).
- Les fichiers peuvent rester marqués comme non résolus jusqu'à ce qu'ils soient marqués comme résolus. Cela empêcherait de pousser / tirer.
Vous pouvez également avoir potentiellement un ensemble de changements comme fusion au lieu d'un seul. Cela vous permettrait d'utiliser toujours des outils tels que git rerere
.
Alors, pourquoi commettre avec des fichiers non résolus est-il mal vu / empêché? Y a-t-il une raison autre que la tradition?
hg 1.6
après une fusion, les fichiers sont marqués comme non résolus. hg
ne pas vous laisser engager jusqu'à ce que vous les avez marqués comme résolu (n'avez - vous signifie pas nécessairement fait pour les résoudre, mais je suppose que l'idée est).
hg
conserve en fait une liste de fichiers qui ont été ou non marqués comme "résolus" (en utilisanthg resolve
). S'il y a des U
fichiers sur cette liste, cela ne vous laissera pas vous engager.
hg resolve
est utilisé spécifiquement pour les fusions avec conflits; voir selenic.com/mercurial/hg.1.html#resolve .Note that Mercurial will not let you commit files with unresolved merge conflicts. You must use hg resolve -m ... before you can commit after a conflicting merge.