Mercurial: "Keine Übereinstimmung gefunden" bei der Zusammenführung, "kein Knoten!" wenn ich versuche,

Question

auszuziehen, habe ich eine mercurial Dropbox, die in einem Dropbox-Ordner gehostet wird, auf dem ich von einem anderen Repo schiebe, den ich in meinem Büro-PC behalte. Auf diese Weise kann ich von meinem Büro aus an meinem Projekt arbeiten und Hotfixes von zu Hause aus durchführen.

Während der Synchronisierung ist etwas Schlimmes passiert, deshalb wurde eine Datei nicht korrekt synchronisiert. Ich habe eine Revision (Nr. 678), die ich nicht mit dem tatsächlichen Kopf verschmelzen kann.

Wenn ich zu verschmelzen versuchen, bekomme ich diese Nachricht

Abbruch: data/hotelsclick/src/main/res/values/string-array.xml.i@5f2b6faa86a1: keine Übereinstimmung gefunden!

wenn ich versuche, die nutzlos Revision mit löschen hg Streifen 678 ich

Abbruch: Daten/Hotelsclick/src/main/res/Werte/string-array.xml.i @ 5f2b6faa86a1: kein Knoten!

und wenn ich ein ausführen hg überprüfen Dies ist das Ergebnis

checking files [...]/src/main/res/values/string-array.xml@678: 5f2b6faa86a1 in manifests not found 

libs/date-interval-picker/.git/index@678: a83e1b77d446 in Manifesten nicht 8009 gefunden Dateien, 681 Changesets, 14161 Totalrevisionen 2 Integritätsfehler aufgetreten! (der erste beschädigte Änderungssatz scheint zu sein 678)

was ist, wenn ich versuche zu drücken?

Suchen nach Änderungen abort: push erstellt neuen Remote-Kopf 16c4912af9a5! (fusionieren oder „hg Hilfe Push“ für Details zu drängen neue Köpfe sehen)

So verschmelzen kann ich nicht, kann diese Revision nicht löschen, kann nicht drücken. Ich bin ziemlich fest und ich weiß nicht warum. Kann mir bitte jemand helfen? Ich interessiere mich nicht für den Inhalt der Revision 678, wenn ich könnte es glücklich löschen.

Danke

Answer 1

Zunächst einmal ich eine Datei-Synchronisierungsdienst (ob Dropbox oder Google Drive oder etwas anderes) für die Verwendung mit Versionskontrollsystemen empfehlen dringend gegen die Verwendung. Diese Dienste berücksichtigen nicht die Atomarität von Repository-Operationen. Selbst Versionskontrollsysteme mit Einzeldatei-Repositories (wie Fossil) sind nicht 100% sicher und selbst wenn nur ein einziger Benutzer den Service nutzt.

Zweitens haben Sie ein teilweise beschädigtes Repository, das Sie reparieren müssen. Im Idealfall haben Sie irgendwo ein sauberes Backup, auch wenn es nicht perfekt auf dem neuesten Stand ist und die fehlenden Revisionen selektiv wiedergeben können (z. B. mit hg export und hg import).

Abgesehen davon wäre der nächste Schritt zu sehen, ob Sie einen Teilklon machen können. Zum Beispiel können Sie versuchen:

Dies sollte in der Regel Revision 678 überspringen, wenn nur diese Daten defekt sind. Wie die Deltakomprimierung funktioniert, können jedoch auch Revisionen sein, die in der Reihenfolge nach 678 auftreten. In diesem Fall würde ich es mit -r 677 anstelle von -r 680 versuchen und sehen, ob hg export zum Kopieren der Revisionen 679 und 680 funktioniert.

Wenn das nicht funktioniert und die Korruption geht tiefer, würde ich versuchen, dann die convert-Erweiterung:

hg --config extensions.convert= convert --config convert.hg.ignoreerrors=True /path/to/repo /path/to/clean_repo 

Beachten Sie, dass eine solche Umwandlung wahrscheinlich die Hash-Werte der einzelnen Repository-Einträge ändern wird und bedeutet, dass Sie müssen den Repository-Inhalt überall aktualisieren.