2017-07-26 2 views
0

Ich bin bei Revision 56, Hash 6af16aa3edf8. Nächste Revision wird 57 sein, mit Hash ???. Gibt es eine Möglichkeit, den Hash von Revision 57 zu kennen? Ich brauche es in einem Pre-Commit-Hook.Get Mercurial nächsten Commit Hash

WARUM THO?

Ich entwickelte ein Skript, das via Pre-Commit-Hook aufgerufen wird, das einige Versionsdateien aktualisiert. Auf diese Weise können die kompilierten ausführbaren Dateien alle Informationen über die Version bereitstellen, aus der sie erstellt wurden. Ich füge die Revisionsnummer des aktuellen Commits in meiner Versionsdatei hinzu, die einfach mit "Parent Revisionsnummer + 1" abgerufen wird. Da die Revisionsnummer bei der Zusammenarbeit mit anderen Personen im selben Repository nicht zuverlässig ist, möchte ich auch den Hash hinzufügen. Ich weiß nicht, wie ich es abrufen kann ...

+0

Hash ist noch weniger zuverlässig, weil ** basierend auf Dateiänderungen ** generiert wird. – arrowd

+0

@arrowd Mit "zuverlässig" meine ich, dass es eine Revision eindeutig identifiziert, während rev Nummer nicht. Hash (Änderungssatz-ID) basiert auf Dateiänderungen UND-Position im Änderungsverlauf. Die vollständigen 40 Ziffern sind für eine bestimmte Revision exklusiv. https://www.mercurial-scm.org/wiki/ChangeSetID –

Antwort

3

Nein, Sie können den nächsten Hash auch dann nicht vorhersagen, wenn Sie den Changeset vollständig kennen. Die begehen Zeit spielt auch eine Rolle dort:

~/hg-test $ hg ci -m "b in foo" 
~/hg-test $ hg id 
d65d61e6898a tip 
~/hg-test $ hg rollback 
~/hg-test $ hg ci -m "b in foo" 
~/hg-test $ hg id 
c7f5ff744e43 tip 

https://www.mercurial-scm.org/wiki/Nodeid

Ich schlage vor, Ihr Problem so lösen: In Ihren Build-Tool, abzufragen, ob das Projekt von einem Repository aufgebaut ist. Wenn ja, rufen Sie die Repository-Informationen ab. Z.B.

ver = $(hg log -r. -T"{node|short} from {date|isodate}") 

geben Ihnen

c7f5ff744e43 from 2017-07-26 14:05 +0200 

Generieren Sie die Versionsdatei aus dieser Information in Ihrer Build-Kette auf das Fliegen

Für Vertriebszwecke erzeugen und diese Datei in das Paket zu ändern, so dass Wenn der Build-Prozess nicht von einem Repository-Checkout aus gestartet wird, verfügt er weiterhin über eine Versionsdatei, die er verwenden kann.

+0

Danke für die Info und die Hinweise. Ich habe über etwas Ähnliches nachgedacht, wie einen Pre-Build-Schritt, bei dem Versionsinformationen basierend auf der aktuellen Version aktualisiert werden. Besser, wenn ich alle Informationen bereit gehabt hätte, wenn ich von einem Commit zum anderen gesprungen bin, aber gut ... –

+0

Ich betrachte diesen Teil des Build-Schritts :) Wenn Sie irgendeine kontinuierliche Integration verwenden, dann haben Sie sowieso die Revisionsinformationen von der Repo selbst - und das Generieren der Versionsinformationsdatei ist Teil des Builds. Wenn Sie Ihren Code für die Verteilung packen, ist es Teil der Paketerstellung, eine kleine Datei mit Versionsinformationen zu generieren. – planetmaker

+1

das Datum angeben :) hg commit -m 'msg' -d "2017-01-01 01:01:01" :) – Tom

Verwandte Themen