Die Standard-Merge-Strategie von AFAIK git ist "rekursiv", dh wenn mehr als ein "gemeinsamer Vorgänger" ein "guter Kandidat" ist, wird git sie zusammenführen und einen neuen "virtuellen gemeinsamen Vorfahren" für die Mitwirkenden erstellen. Es hilft im Grunde, Situationen zu lösen, in denen Dateien bereits zusammengeführt wurden und es vermeidet, sie erneut zusammenzuführen oder falsche Zusammenführungsbeiträge zu erzeugen.
Meine Frage ist: Wenn Mercurial nicht "rekursiv" verwendet, wie behandelt es die gleiche Situation?
Danke
Die meisten Versionskontrollsysteme wissen nicht, wie sie mit einer Situation umgehen sollen, in der mehrere Basisversionen für eine Zusammenführung vorhanden sind. Die mathematische Mischungsgleichung ist
Result = Destination + SumOf(I=1-N)(Base(I) - Source(I))
In den meisten Fällen ist N = 1 und Sie haben eine klassische Zusammenführung mit Quell-, Ziel- und Basisversionen, die ein typisches 3-Wege-Merge-Tool verarbeiten kann. Obwohl viele Quellcodeverwaltungssysteme selbst in diesem einfachen Fall keinen korrekten Algorithmus zum Auffinden der Basisversion haben. Um dies zu tun, müssen Sie zurück durch den Versionsbaum gehen, der die Merge-Pfeile hinaufgeht, bis Sie sich bei einem gemeinsamen Vorfahren treffen. Aber manchmal ist der gemeinsame Vorfahre zu weit entfernt und passt nicht zu der obigen Gleichung für N = 1, und in diesem Fall müssen Sie mehrere gemeinsame Vorfahren für mehrere Teilverschmelzungen finden.
Beispiel wäre ein Fall, bei dem eine Verzweigung mehrere Male nach unten und oben zusammengeführt wird, dann versuchen wir, die Änderungen von dieser Verzweigung zu einer anderen Verzweigung zusammenzuführen. In diesem Fall ist der N & gt; 1, aber niedriger als die Anzahl der Zusammenführungen im Quellzweig.
Dies ist eine der schwierigsten Aufgaben beim Zusammenführen von Zweigen und ich kenne kein Quellcodeverwaltungssystem, das es wirklich korrekt macht.