Mercurial Repository Beschädigung

14

Dies hängt etwas mit dieser Frage zusammen , ist aber eine andere Frage.

Wir haben ein zentrales Hg-Repository, das den Benutzern über SSH und Quecksilberserver zur Verfügung steht . Wir haben eine Reihe von Mac-, Linux- und Windows-Clients, die eine Verbindung herstellen.

Es ist nun zweimal vorgekommen, dass einer der Windows-Benutzer sein Repository beschädigt und dann auf das zentrale Repository zurückgeschoben hat, das es beschädigt hat. Ich möchte ein eingehendes Hook-Skript in das zentrale Repository schreiben, um zu verhindern, dass eine Transaktion akzeptiert wird, wenn dadurch das zentrale Repository beschädigt wird.

Obwohl ich leider nicht genug über Mercurial weiß, um ein solches Skript zu schreiben. Gibt es eine Möglichkeit, dass jemand anderes darauf gestoßen ist? Persönlich bin ich mir nicht ganz sicher, warum hg dies nicht standardmäßig tut.

mercurial corruption

— Bobinabottle
quelle

Ich habe hier eine Lösung gefunden: davidherron.com/blog/topics/… , die auf allen Clients durchgeführt werden müsste. Aber wenn jemand eine bessere Lösung hat, die für das zentrale Repo selbst getan werden kann, wäre das besser.

— Bobinabottle

Bitte geben Sie uns weitere Details: Welche Mercurial-Version verwenden Sie auf dem Server und auf jedem der Clients?

— Martin Geisler

2

Außerdem wäre es für uns (die Mercurial-Entwickler) äußerst nützlich, wenn Sie dies reproduzieren könnten. Bitte melden Sie uns solche Probleme auch direkt über unsere Mailingliste: mercurial.selenic.com/wiki/MailingLists oder Bug Tracker: selenic.com/mercurial/bts Das ist viel produktiver als hier zu posten :-)

— Martin Geisler

4

Neuere Versionen von Mercurial (seit 1.5) unterstützen die Validierung eingehender Daten. Hinzufügen

[server]
validate = True

in der hg config Ihres Servers (entweder .hg/hgrcoder die hgwebdir config sollte gut funktionieren), damit der Server eingehende Daten überprüft und ungültige Pushs ablehnt. Der Client wird dann einen Fehler sehen, der ungefähr so aussieht:

remote: abort: missing file data for beta:dddc47b3ba30e54484720ce0f4f768a0f4b6efb9 - run hg verify

Ich hoffe, das hilft!

— durin42
quelle

2

Vielleicht solltest du es vermeiden, alles in ein Repository zu verschieben. Mit Mercurial und seiner verteilten Natur kann jeder seinen Zweig haben, und wenn er sich bereit fühlt, sagt er es dir und du ziehst daran. Keine Commit-Zugriffsprobleme, kein Push, der Sachen kaputt macht ...

Dies ist zumindest ein Rat, den mir ein Freund gegeben hat, als ich von SVN nach Mercurial migriert bin.

Ich weiß nicht, ob dies eine Option für Sie ist, aber wenn Sie ein persönliches Repository für alle einrichten und dann die benötigten Personen abrufen, ist möglicherweise weniger Arbeit erforderlich, als wenn Sie versuchen, gefährliche Stöße abzufangen.

— AdamTheCamper
quelle

Nicht drängen zu HG besiegt seinen ganzen Zweck - mehrere Benutzer arbeiten zusammen

— Anonymouse

0

Könnten Sie nicht das Gleiche tun wie David Herrons Blog , aber anstatt es beim Prerouting zu tun, tun Sie es mit dem Precommit-Haken am zentralen Repo?

— Ryan Gibbons
quelle

Nö :-( Ich habe es versucht, aber es kommt zu einem Deadlock. Wenn ein Client versucht, einen Push auszuführen, reserviert er eine Sperre für das Repository. Für die Ausführung einer 'hg verify' ist auch eine Sperre erforderlich eine endlose Schleife

— Bobinabottle

Selbst wenn dies bei einem Precommit funktioniert hätte, würde es das Repository überprüfen, prüfen, ob es in Ordnung ist, und dann die Änderungen festschreiben, die es beschädigen würden. Wirklich, ich würde einen Haken brauchen, um zu beurteilen, ob die eingehenden Änderungen die Repos beschädigen würden, wenn ja, die Transaktion rückgängig machen. Es wäre also sinnvoller, am Haken der Änderungsgruppe zu sein.

— Bobinabottle

(Die Verwendung des Changeloup-Hakens führt immer noch zu Deadlocks.)

— Bobinabottle

Interessant - die Hooks scheinen pythonbasiert zu sein. Wissen Sie, was das Repository beschädigt? Ist jedes Mal das Gleiche?

— Ryan Gibbons

0

Eine mögliche Alternative ist:

Klonen Sie das Repository NACH dem Push.
Überprüfen Sie es.
Wenn das Repository fehlerfrei ist, archivieren Sie es als das neueste fehlerfreie
Wenn das Repository beschädigt ist, lösen Sie einen Alarm aus
Stellen Sie im Alarmfall das letzte bekannte funktionierende Repository wieder her.

Diese Lösung ist nicht die, die Sie benötigt haben, aber Sie haben zumindest die Möglichkeit, Ihr Repository im Falle einer Beschädigung zurückzusetzen.

— Laurent Etiemble
quelle