Build-Sequenzierung bei verteilter Versionskontrolle

Question

Im Moment verwenden wir Perforce für die Versionskontrolle. Es hat die praktische Funktion einer streng aufsteigenden Änderungsnummer, die wir verwenden können, um auf Builds zu verweisen, z. B. "Sie erhalten den Bugfix, wenn Ihr Build mindestens 44902 ist".

Ich würde gerne auf ein verteiltes System (wahrscheinlich git) umsteigen, um das Branching und die Arbeit von zu Hause aus zu erleichtern. (Beides ist mit Perforce durchaus möglich, aber der Git-Workflow hat einige Vorteile.) Obwohl die "tributary development" also verteilt wäre und sich nicht auf eine gemeinsame Revisionsreihenfolge beziehen würde, würden wir immer noch ein Master-Git-Repository unterhalten, in das alle Änderungen einfließen müssten, bevor ein Build erstellt wird.

Wie bewahrt man am besten strikt zunehmende Build-IDs? Der einfachste Weg, den ich mir vorstellen kann, ist, eine Art Post-Commit-Hook zu haben, der immer dann ausgelöst wird, wenn das Master-Repository aktualisiert wird, und der den Hash des neuen Tree-Objekts (oder Commit-Objekts? Ich bin neu in Git) in einer zentralen Datenbank registriert, die IDs vergibt. (Ich sage "Datenbank", aber ich würde es wahrscheinlich mit Git-Tags machen, und einfach nach der nächsten verfügbaren Tag-Nummer oder so etwas suchen. Die "Datenbank" wäre also eigentlich .git/refs/tags/build-id/.)

Das ist machbar, aber ich frage mich, ob es eine einfachere oder bereits implementierte oder standardisierte/"bewährte" Methode gibt, dies zu erreichen.

Answer 1

Ich würde "Labels" verwenden. Erstellen Sie ein Label, wenn Sie einen erfolgreichen (oder auch erfolglosen) Build haben, und Sie werden diesen Build für immer identifizieren können. Es ist nicht ganz dasselbe, aber es bietet diese Build-Nummern, während es immer noch die Vorteile der verteilten Entwicklung bietet.

Answer 2

Wie Sie wahrscheinlich wissen, berechnet Git einen Hash (eine Zahl), der einen Knoten der Historie eindeutig identifiziert. Die Verwendung dieser Hash-Werte, auch wenn sie nicht unbedingt ansteigend sind, scheint gut genug zu sein. (Noch besser, sie immer entsprechen dem Quelltext, d.h. wenn Sie den Hash haben, haben Sie denselben Code). Es sind große Zahlen, aber meistens kommt man mit 6 oder so der führenden Ziffern aus.

Zum Beispiel,

Dieser Fehler wurde in 064f2ea behoben...

Answer 3

Mit Mercurial können Sie den folgenden Befehl verwenden:

# get the parents id, the local revision number and the tags
[yjost@myhost:~/my-repo]$ hg id -nibt
03b6399bc32b+ 23716+ default tip

Siehe hg identifizieren