Verwenden Sie Subversion ohne Kofferraum

Question

Mein Team hat kürzlich beschlossen, den "Trunk" -Ast nicht zu verwenden, der typisch für die meisten Subversion -Repository -Layouts ist. Wir fanden heraus, dass es zu jedem Zeitpunkt immer einen bestimmten Zweig gab, der in der traditionellen Rolle, die Rumpf in anderen Repositorys innehat, funktionierte. Das heißt, wir haben immer einen Zweig mit höchster Zahlen, der die nächste Veröffentlichung darstellt, an der wir arbeiten. Daher ist eine Zusammenführung zum Kofferraum einfach überflüssig, also haben wir Rumpf losgeworden.

Macht das noch jemand da draußen?

Wenn ja, haben Sie Vor-/Nachteile bemerkt?

Auch wenn Ihr Team dies nicht tut, hat jemand irgendwelche Gedanken zu diesem Layout?

Answer 1

Sie sprechen über das der Werbemodell - Perforces Papier unterstreicht die Probleme damit - kommunizieren die sich ändernden Rollen von Codelinien und die beweglichen Arbeit zwischen Zweigen.

Eine Erweiterung meiner Ansichten über die aufgeführten Probleme:

1) Änderung der Richtlinien von Codelinien:

Jede Code -Zeile hat eine Richtlinie, egal ob sie niedergeschrieben und formalisiert oder vollständig im Kopf eines Entwicklers impliziert ist. Es definiert EG:

• Wer darf sich auf die Codezeile festlegen
• Wie viel Tests sind erforderlich (z. B. müssen die Unit -Tests bestehen, Regressionstests, vollständige Systemtests)
• Wie viele Personen müssen Änderungen der Überprüfung codieren?
• Welche Änderungen sind erlaubt?

Mit dem Stammansatz bleiben die Richtlinien festgelegt und sind daher einfacher zu schreiben, was es einfacher zu kommunizieren macht (wichtiger in einem größeren Team).

zB Trunk:

• Jeder Entwickler kann sich verpflichten
• jede Änderung
• Unit -Tests müssen bestehen
• Code -Überprüfung nach dem Commit

Versionszweig:

• Nur Wartungsentwickler
• Nur Fehlerbehebung
• Unit -Test + Regressionstests
• Code -Überprüfung durch 2 andere Entwickler vor dem Commit

Tag -Zweig:

• Keine Commits nach der Schöpfung

Private Zweigstelle des Entwicklers:

• Nur der Entwickler schaut sich an
• Jede Änderung
• Testen erst vor der Verschmelzung zum Kofferraum
• Code -Überprüfung vor der Zusammenführung zu Trunk

Wenn Sie das Promotion -Modell haben, haben Sie eine Richtlinie in der Hauptentwicklung und müssen dann allen mitteilen, wenn Sie die Richtlinien während der Vorbereitung auf die Veröffentlichung ändern, und dann eine weitere Richtlinie (für die Code -Linie), sobald die Zeile veröffentlicht wird.

Das Promotion-Modell ist leicht zu erreichen und kartiert direkt auf die Arbeitsweise der Nicht-Source-Kontrolle. Aber es tut weh, wenn Sie anfangen, große Teams zu bekommen.

Wenn Sie sich die Entwicklung von Linux -Kernel ansehen, können Sie den Dehnungsstamm zwischen dem Werbemodell und dem Rumpfmodell: Linus 'Baum bewerben - er durchläuft die Zyklen zwischen dem Zusammenführungsfenster und der RC/Stabilisierungsperiode. Aber Linux -Next und -mm sind entstanden, um eine kofferartigere Linie zu geben.

Verteilte SCM/VCs sind sowieso etwas anders, die Richtlinien müssen nicht an alle Entwickler verteilt werden, da jede Entwicklung seine eigenen Bäume hat und Änderungen anziehen, wenn er will.

Open-Source-Projekte leiden unter dem Problem, dass sie die Menschen nicht zwingen können, die Stabilisierung einer Freilassung nach der Verzweigung vom Kofferraum zu stabilisieren. Daher ist das Promotion -Modell wichtiger, um Stabilisierungsbemühungen zu erzwingen, anstatt nur an Merkmalen zu arbeiten.

2) Umzugsarbeit:

Ein Entwickler arbeitet möglicherweise an einer Funktion, wenn die Richtlinie für die Zeile, an der er nur Änderungen an Bug-Fixes arbeitet, jetzt seine Arbeitskopie in eine andere Codelinie umstellen muss. Dies kann von einfach bis extrem schwierig sein, je nach dem in verwendeten SCM -System. Dieses Problem tritt nicht auf, wenn der Entwickler am Kofferraum arbeitet, da seine Arbeit immer zum Kofferraum wird. Wenn sich der Entwickler in einer privaten oder feature -Filiale befindet, beeinträchtigt seine Arbeiten nur auf Kofferraum (und die Veröffentlichung).

Wenn eine Funktion bereits eingecheckt ist, sich jedoch von der Version, in der sie sich derzeit befindet, verzögert wird, müssen Sie herausfinden, wie Sie sie entfernen. Dieses Problem gibt es immer noch mit dem Trunk -Modell, könnte aber ein wenig einfacher zu lösen sein - Cherry -Picking -Dinge aus dem Kofferraum für die Veröffentlichung. Hier helfen Feature -Zweige - aber sie haben Integrationskosten.

Answer 2

Mein Problem mit dem Perforce -Papier ist, dass es das Werbemodell zurückweist, ohne den Hauptvorteil zu erwähnen, reduziertes Verschmelzungsaufwand. Tatsächlich gibt das Papier fälschlicherweise an, dass das "Hauptmodell" "keinen zusätzlichen administrativen Overhead" auferlegt, eine lächerliche Behauptung. Das Modell "Immer zusammen mit dem Kofferraum" bedeutet genau das - Sie haben den Overhead, dass jeder verschmelzen muss. Dies ist sinnloser Overhead, wenn Sie die folgende Situation haben (die wir haben):

a) Ein kleines Team (5 bis 7 Entwickler) alle in der rufigen Entfernung voneinander. Kommunikation ist ein Nicht-isue, wenn wir einen Zweig machen müssen

und

b) Eine Codebasis, bei der es wirklich nur 2 große Zweige gibt - eine Produktionszweig und "das nächste, was in der Entwicklung" ist. Vielleicht haben wir einmal in einem blauen Mond 3.

Ich denke, mein Punkt ist - es ist eine Situation. Zu sagen, dass das "Werbemodell Probleme hat" ist wie "Niemals einen oder/m" zu sagen. Es hängt von Ihrer Umgebung ab.

Answer 3

Subversion ermöglicht beide Ansätze. Der Kofferraum ist keine Notwendigkeit, sondern eine Konvention. Wenn Sie es haben, funktionieren einige Tools leichter (z. B. Migrationstools für Git). Wenn Sie es nicht haben, müssen Sie einige Dinge manuell tun, aber ich kann mir nichts vorstellen, was Sie während Ihrer täglichen Arbeit bemerken werden.

Answer 4

Ich habe kürzlich mit der Arbeit an einem Projekt begonnen, das sich in einem Subversion -Repository befindet. Wer das Repository erstellt hat, folgte kein bestimmtes Layout - sie haben einfach alles in die Wurzel des Repositorys gestopft (kein Koffer/, keine Zweige/und sicherlich keine Tags/). Ich wollte einen Zweig erstellen, an dem ich arbeiten kann, und einige Tags für andere Dinge, aber ich erkannte, wie schwierig es ist, dies auf einem Subversion -Repository zu tun, das kein ordnungsgemäßes Layout folgt.

Answer 5

Wir tun - irgendwie. Wir verwenden keinen Kofferraum, sondern erstellen einen neuen Zweig für jede Veröffentlichung unserer Projekte. Diese "markierte" Filiale ist dann der Kofferraum für jede Version, und wir haben Fehler zurück, indem wir Änderungen an den älteren Veröffentlichungen verschmelzen.

Es funktioniert gut für uns, aber wir haben viele Unterprojekte in unserem Projekt.

Answer 6

IME, in einigen Umgebungen ist der Kofferraum ein guter Ort, um die Korrekturen und Änderungen an/von zu tauschen. Das heißt, jeder verschmilzt seine Fixes zu der Kofferraum und jeder verschmilzt die Korrekturen anderer aus der Kofferraum. Wir fanden dies sehr hilfreich in einer Umgebung, in der viel Code unter vielen unabhängigen Projekten geteilt wurde und in dem all diese Projekte zum gemeinsam genutzten Code beitrugen.

Ihre Umgebung kann sich jedoch unterscheiden.