Verwenden von Subversion mit dem Promotionsmodell

Question

Momentan verwenden wir Subversion für die Quellcodeverwaltung, aber alle Zusammenführungsarbeiten für unsere Releases werden manuell durchgeführt. Wir veröffentlichen mehrmals im Jahr, also erstellen Sie für jede Veröffentlichung einen Zweig. Alle Arbeiten aus früheren Zweigen müssen in spätere verzweigen. Arbeiten an späteren Filialen dürfen nicht in frühere Filialen gehen (dies ist in unseren Verträgen). Ich glaube, das ist bekannt als das Promotionsmodell.

Ich denke, das folgende Diagramm veranschaulicht am besten unseren angestrebten Arbeitsablauf, wobei Verzweigungen immer dann erstellt werden, wenn die Arbeit an einer neuen Version beginnt, und Änderungen von früheren Verzweigungen zu späteren.

 
| 
1 
| 
|\ 
| \ 
| 2 
3 | 
|\| 
4 | 
| |\ 
5 | \ 
| 6 | 
| | 7 
|\|\| 
| |\| 
8 9 |\ 
| | | \ 
|\| | 10 
x |\| | 
    | |\| 
    | | | 

a b c d 

• Würde dieses Modell arbeitet reibungslos mit Subversion trotz des Mangels an einem sinnvollen Stamm?
• Würde automatisierte Merge-Tracking für die Updates von früheren Zweigen zu späteren arbeiten?
• Wäre es in Ordnung, einen Zweig zu schließen/zu löschen/zu ignorieren (in diesem Beispiel den Zweig 'a' freizugeben), ohne erneut zu integrieren?
• Wäre es in Ordnung, Feature-Zweige aus jedem Release-Zweig zu erstellen, und Tracking-Arbeit für diese zusammenführen? (Sie folgen dem empfohlenen Modell zum Erstellen/Zusammenführen/Reintegrieren.)

Bearbeiten - Weitere Informationen.

Der Grund, warum das traditionelle Instable Trunk-Modell möglicherweise nicht geeignet ist, wird anhand des folgenden Diagramms veranschaulicht. Die Funktionen für jede Version werden nicht unbedingt in der Reihenfolge der Veröffentlichung abgeschlossen (manche Kunden können die Anforderungen nur langsam bestätigen). Wir wollen so schnell wie möglich Änderungen von früheren Zweigen zu späteren verbreiten.

 
    a 
    | 
    1 
    | 
    b|\ a 
    | \ 
    | 2 
    3 | 
    | | 
    4 | 
    b/|c | 
/5 | 
| | 6 
7 | | 
b c a 

In diesem Fall wollen wir Merkmal 2 (im Zweig ein abgeschlossenen) im Zweig b, aber da dies ein Kind zu übergeordneter Zusammenführung, und daher nicht von Subversion unterstützt wird, wird es getan werden muss manuell. In ähnlicher Weise müsste Feature 6 zweimal manuell zusammengeführt werden. Ich erwarte, dass dies ein relativ langsamer und fehleranfälliger Prozess im Vergleich zu automatisch nachverfolgten Zusammenführungen ist.

Answer 1

Wenn ich Ihre Situation verstehe, gibt es nichts in Ihren Anforderungen, das die Dinge so komplex macht, wie Sie es scheinen. Sie legen auch viel zu viel Wert auf die Vorteile von automatischem oder manuellem Mergen (mehr dazu später). CVS-Zweige wären eine andere Sache gewesen, aber nicht mit der Art und Weise, wie SVN "Zweige" handhabt (d. H. Es tut dies nicht).

Sie könnten eine primäre (instabile oder stabile) Entwicklungslinie haben und Zweige für jeden Kunden oder Release (oder beide) erstellen. Wenn Features validiert werden, werden sie entweder mit der Hauptlinie zusammengeführt, sodass spätere Zweige diese Änderungen enthalten können, oder Sie werden immer unidirektional von einem übergeordneten Zweig zusammengeführt. Nichts erfordert, dass Sie die Verzweigung schließen und die Zusammenführung ist nicht weniger automatisiert als es wäre, um Ihr erstes (chaotisches) Diagramm zu unterstützen, vorausgesetzt, Sie haben mehrere parallele Entwicklungslinien.

Die Anforderung, dass nur Vorwärtsgeräusche zusammengeführt werden, besteht darin, dass Sie nur Teilmengenrevisionen aus der Hauptlinie zusammenführen müssen, Revisionen nach einer bestimmten Zweigrevision. Wenn Sie Ihre Zusammenführungen auf diese Weise durchführen, können Sie Änderungen von beliebigen Verzweigungen so oft wie gewünscht in die Hauptlinie zusammenführen (wie sie von Ihren Kunden bestätigt werden) und können mit der Gewissheit angewendet werden, dass nur validierte Änderungen angewendet werden. Sie können eine automatische Zusammenführung einrichten, um diese Kopierrevision nachzuverfolgen (siehe - Stop-on-Copy und bereichsbasierte Zusammenführungen). Geben Sie Zweige frei, und nehmen Sie dann Sätze von bestätigten Änderungen auf, die von einem bestimmten Punkt an nach vorne gegangen sind.

SVN "track merges" nicht mehr als es Zweige unterstützt (was es nicht tut, sie sind nur leichte Kopien). Sie sagen es (oder svnmerge sagt es) Bereiche zu verbinden und es gilt diese Änderungen. Sie können den Effekt erzielen, den Sie vertraglich benötigen, unabhängig davon.

Um Ihre gestellten Fragen zu beantworten:

• Ich glaube nicht, das Modell, das Sie sehr effektiv vorgeschlagen ist. Im Gegenteil, es hat das Potenzial für das Feature-Tracking-Chaos erhöht, da Sie möglicherweise Zweige nach Änderungen scannen und mehrfach zusammenführen müssen. Darüber hinaus wird es zweifellos Entwickler verwirren, die mit SVN und traditionelleren SVN-Organisationsstrukturen vertraut sind.

• Sicher. Das sollte ziemlich unabhängig von der gewählten Struktur sein. Sie werden Ihre Revisions-Punkte unabhängig davon behalten müssen (vielleicht durch ein paar einfache Scripts im schlechteren Zustand).

• Sicher. Zweige haben in SVN auf der Serverseite effektiv keine Kosten. Die Client-Seite hat Kosten, wenn Sie ganze Root-Checkouts machen, aber das ist in der Regel eine dumme Sache, egal wie. Ebenso gibt es kein Problem, einen Zweig zu ignorieren/zu löschen. Es ist nur eine weitere Änderung der globalen Revisionshierarchie wie jede andere Kopie/Löschen/Umbenennen/etc.

• Das sollte unabhängig von der "verzweigenden" Organisationsstruktur funktionieren. Es klingt, als gäbe es vielleicht ein bisschen Missverständnis darüber, was es bedeutet, ein "Zweig" in SVN zu sein. Sie sollten in der Lage sein, das, was Sie wollen, einzurichten und manuelle Zusammenführungen relativ einfach durchzuführen und später das automatische Zusammenführen nach einigen Kundenaktualisierungen einzurichten, damit Sie Ihre Zusammenführungsschritte ein wenig besser verstehen können.

Prost!

Answer 2

Sie sagen:

Alle Arbeiten aus früheren Zweigen müssen es in späteren machen. Die Arbeiten an später Zweige nicht in frühere diejenigen machen müssen (dies ist in unseren Verträgen)

Hier wird, wenn wir Zweige mit Freisetzungen ersetzen (ich bezweifle, Ihre Kunden wissen, oder kümmern uns um „Zweige“), erhalten wir :

Alle Arbeiten aus früheren Releases müssen es in späteren machen. Die Arbeiten an später Releases darf es nicht in früheren diejenigen machen (dies ist in unseren Verträgen)

Ich sehe nichts in dieser Anforderung, die sehr komplexe Verzweigungsschema schlagen Sie schlagen - Sie dies tun können mit dem klassischen Entwicklungsstil "Unstable Trunk". Entweder haben Sie mehr Anforderungen, von denen Sie uns noch nichts gesagt haben, oder Sie sind überbeansprucht.