Sie sollten beides tun .
Beginnen Sie mit der akzeptierten Antwort von @Norman: Verwenden Sie ein Repository mit einem benannten Zweig pro Version.
Lassen Sie dann einen Klon pro Release-Zweig erstellen und testen.
Eine wichtige Anmerkung ist, dass Sie, selbst wenn Sie mehrere Repositorys verwenden, das transplant
Verschieben von Änderungssätzen zwischen diesen vermeiden sollten, da 1) der Hash geändert wird und 2) Fehler auftreten können, die sehr schwer zu erkennen sind, wenn zwischen den Änderungssätzen widersprüchliche Änderungen bestehen Transplantation und der Zielzweig. Sie möchten stattdessen die übliche Zusammenführung durchführen (und ohne Vorab-Zusammenführung: Überprüfen Sie die Zusammenführung immer visuell), was zu dem führt, was @mg am Ende seiner Antwort gesagt hat:
Das Diagramm sieht möglicherweise anders aus, hat jedoch dieselbe Struktur und das Endergebnis ist dasselbe.
Wenn Sie mehrere Repositorys verwenden, enthält das "Trunk" -Repositorium (oder Standard-, Haupt-, Entwicklungs- usw. ) ALLE Änderungssätze in ALL - Repositories. Jedes Release- / Zweig-Repository ist einfach ein Zweig im Trunk, der auf die eine oder andere Weise wieder zum Trunk zusammengeführt wird, bis Sie ein altes Release zurücklassen möchten. Daher besteht der einzige wirkliche Unterschied zwischen diesem Haupt-Repo und dem einzelnen Repo im benannten Zweigschema einfach darin, ob Zweige benannt sind oder nicht.
Das sollte deutlich machen, warum ich "mit einem Repo beginnen" sagte. Dieses einzelne Repo ist der einzige Ort, an dem Sie jemals nach Änderungen in einer Version suchen müssen . Sie können Änderungssätze in den Release-Zweigen für die Versionierung weiter kennzeichnen. Es ist konzeptionell klar und einfach und vereinfacht den Systemadministrator, da es das einzige ist, das unbedingt jederzeit verfügbar und wiederherstellbar sein muss.
Dann müssen Sie jedoch noch einen Klon pro Zweig / Release verwalten, den Sie erstellen und testen müssen. Es ist so trivial wie möglich hg clone <main repo>#<branch> <branch repo>
, und dann werden hg pull
im Zweig-Repo nur neue Änderungssätze für diesen Zweig abgerufen (plus Ahnen-Änderungssätze für frühere Zweige, die zusammengeführt wurden).
Dieses Setup am besten passt das Linux - Modell begehen Kernel Single Puller (sieht es nicht gut fühlen , wie Herr Linus zu handeln. Bei uns nennen wir die Rolle Integrator ), da die Haupt Repo das einzige , was Entwickler benötigen , um Klon ist und die Abzieher muss hineinziehen. Die Wartung der Filialrepos dient ausschließlich dem Release-Management und kann vollständig automatisiert werden. Entwickler müssen niemals von den Zweigstellen-Repos ziehen.
Hier ist das Beispiel von @ mg, das für dieses Setup neu erstellt wurde. Startpunkt:
[a] - [b]
Erstellen Sie einen benannten Zweig für eine Release-Version, z. B. "1.0", wenn Sie zur Alpha-Version gelangen. Beheben Sie Fehlerbehebungen:
[a] - [b] ------------------ [m1]
\ /
(1.0) - [x] - [y]
(1.0)
ist kein wirklicher Änderungssatz, da der benannte Zweig erst existiert, wenn Sie ihn festschreiben. (Sie können ein triviales Commit durchführen, z. B. ein Tag hinzufügen, um sicherzustellen, dass benannte Zweige ordnungsgemäß erstellt werden.)
Die Zusammenführung [m1]
ist der Schlüssel zu diesem Setup. Im Gegensatz zu einem Entwickler-Repository, in dem eine unbegrenzte Anzahl von Köpfen vorhanden sein kann, möchten Sie NICHT mehrere Köpfe in Ihrem Haupt-Repo haben (mit Ausnahme des alten, toten Release-Zweigs, wie zuvor erwähnt). Wenn Sie also neue Änderungssätze für Release-Zweige haben, müssen Sie diese sofort wieder in den Standardzweig (oder einen späteren Release-Zweig) zurückführen. Dies garantiert, dass alle Fehlerbehebungen in einer Version auch in allen späteren Versionen enthalten sind.
In der Zwischenzeit wird die Entwicklung des Standardzweigs in Richtung der nächsten Version fortgesetzt:
------- [c] - [d]
/
[a] - [b] ------------------ [m1]
\ /
(1.0) - [x] - [y]
Und wie üblich müssen Sie die beiden Köpfe im Standardzweig zusammenführen:
------- [c] - [d] -------
/ \
[a] - [b] ------------------ [m1] - [m2]
\ /
(1.0) - [x] - [y]
Und das ist der 1.0-Zweigklon:
[a] - [b] - (1.0) - [x] - [y]
Jetzt ist es eine Übung, den nächsten Release-Zweig hinzuzufügen. Wenn es 2.0 ist, wird es definitiv vom Standard abweichen. Wenn es 1.1 ist, können Sie zwischen 1.0 und Standard wählen. Unabhängig davon sollte jeder neue Änderungssatz für 1.0 zuerst mit dem nächsten Zweig und dann mit dem Standardzweig zusammengeführt werden. Dies kann automatisch erfolgen, wenn kein Konflikt vorliegt, der lediglich zu einer leeren Zusammenführung führt.
Ich hoffe, das Beispiel macht meine früheren Punkte klar. Zusammenfassend sind die Vorteile dieses Ansatzes:
- Einziges autorisierendes Repository, das den vollständigen Änderungssatz und den Versionsverlauf enthält.
- Klares und vereinfachtes Release-Management.
- Klarer und vereinfachter Workflow für Entwickler und Integratoren.
- Erleichtern Sie Workflow-Iterationen (Codeüberprüfungen) und Automatisierung (automatische leere Zusammenführung).
UPDATE hg selbst macht das : Das Haupt-Repo enthält die Standard- und Stable-Zweige, und das Stable-Repo ist der Stone-Branch-Klon. Es wird jedoch kein versionierter Zweig verwendet, da Versions-Tags entlang des stabilen Zweigs für die Release-Verwaltung gut genug sind.