Wann sollte ein Multi-Modul-Projekt in separate Repository-Bäume aufgeteilt werden?

Question

Derzeit haben wir ein Projekt mit einem Standard-Subversion-Repository Layout:

./trunk
./branches
./tags

jedoch, wie wir bewegen den Weg der OSGi nach unten und einem

./trunk/bundle/main
./trunk/bundle/modulea
./trunk/bundle/moduleb ./tags/bundle/main-1.0: modulares Projekt haben wir mit enden. 0
./tags/bundle/main-1.0.1
./tags/bundle/modulea-1.0.0

Die 'Build' ist immer noch ziemlich monolithisch, dass sie alle Module in Sequenz baut, obwohl ich beginne zu fragen, ob wir die Build/Repository etwas mehr wie Refactoring sollte:

./bundle/main/trunk
./bundle/main/tags/main-1.0.0
./bundle/main /tags/main-1.0.1
./bundle/modulea/trunk
./bundle/modulea/tags/modulea--1.0.0

In diesem Muster würde ich mir vorstellen, dass jedes Modul sich selbst erstellt und seine Binärdatei in einem Repository speichert (Maven, Efeu oder ein anderer Pfad des Subversion-Repositorys selbst).

Gibt es Richtlinien oder 'Best-Practices' über Projekt-Layouts, wenn man modular wird?

Answer 1

Das Subversion Buch enthält zwei Abschnitte dazu:

• Repository Layout
• Planning Your Repository Organization

Ein Blog-Eintrag zum Thema: "Subversion Repository Layout"

Die kurze Antwort, aber: während Kilometerstand wird variieren (jede Situation ist individuell), Ihr /bundle/<project>/(trunk|tags|branches) Schema ist ziemlich üblich und wird wahrscheinlich gut für Sie arbeiten.

Answer 2

Das ist sehr viel bis zu persönlichen Vorlieben, aber ich finde, die aus der folgenden Struktur geeignet für große Projekte aus vielen Modulen:

 
branches 
    project-name 
    module1 
     branch-name 
    module2 
     possibly-another-branch-name 
    branch-name-on-a-higher-level-including-both-modules 
     module1 
     module2 
tags 
    ... (same as branches) 
trunk 
    project-name 
    module1 
    module2 

Ich habe oft auch die Struktur in großen Repositories enthalten viele Projekte verwendet, da Wenn Sie alle Projekte im selben Repository aufbewahren, können Sie Querverweise auf Projekte erstellen und Code zwischen ihnen austauschen — mit Verlauf — einfacher.

Ich benutze gerne die Struktur mit Stammstamm, Tags und Zweige Ordner von Anfang an, da nach meiner Erfahrung (mit großen Repositories mit vielen Projekten), viele Unterprojekte und Module nie separate Tags oder Zweige haben wird Es ist nicht notwendig, die Ordnerstruktur für sie zu erstellen. Es erleichtert den Entwicklern auch, den gesamten Stamm des Repositorys zu überprüfen und nicht alle Tags und Zweige zu erhalten (die sie nicht die meiste Zeit benötigen).

Ich denke, das ist eine Frage der Projekt- oder Firmenpolitik. Wenn Sie ein Repository für jedes Projekt haben oder ein bestimmter Entwickler nur zu einem bestimmten Zeitpunkt an einem einzelnen Projekt im Repository arbeiten kann, ist der Stammwurzel möglicherweise nicht so sinnvoll.

Answer 3

Ich habe eine ähnliche Frage in einem StackOverflow Version Control Structure question beantwortet. Es passt sogar noch besser hier, da wir eine schwere OSGi-Entwicklung machen und viele Bundles haben. Ich muss die Kommentare von Anders Sandvig wiederholen: trunk/tags/branches auf Root-Ebene beibehalten, da nur eine begrenzte Anzahl von Modulen verzweigt wird. Es stört auch nicht, Module einzeln aufzubauen.

Ich werde nicht die Antwort kopieren, die ich zuvor gemacht habe, aber es ist völlig relevant für diese Frage.

Answer 4

Just my two cents ...

Ich möchte nur den Kommentar in der Dokumentation SVN betonen (bereits in einer anderen Antwort zitiert selben Thread) http://svnbook.red-bean.com/en/1.4/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

Der Auszug verweist die folgende Struktur: / Stamm/ calc/ Kalender/ Tabelle/ ... tags/ calc/ Kalender/ Tabelle/ ... branches/ calc/ Kalender/ Tabelle/

„Es gibt nichts besonders falsch über ein solches Layout, aber es kann oder auch nicht so intuitiv für die Benutzer zu sein scheinen. Insbesondere in großen Situationen mit mehreren Projekten mit vielen Benutzern sind diese Benutzer möglicherweise mit nur einem oder zwei der Projekte im Repository vertraut. Aber die Projekt-as-Branch-Geschwister tendieren dazu, die Individualität des Projekts abzubauen und konzentrieren sich auf das gesamte Set von Projekten als eine Einheit. Das ist jedoch ein soziales Problem. Wir mögen unsere ursprünglich vorgeschlagene Anordnung aus rein praktischen Gründen - es ist einfacher, den gesamten Verlauf eines einzelnen Projekts zu fragen (oder zu ändern oder zu migrieren), wenn es einen einzigen Repository-Pfad gibt, der den gesamten Verlauf enthält - Vergangenheit, Gegenwart, Kennzeichnung und . verzweigten für dieses Projekt und das Projekt allein“

für meine eigenen, neige ich dazu, mit dieser und bevorzugte das folgende Layout sehr stark zustimmen: / utils/ calc/ trunk/ tags/ branches/ Kalender/ Stamm/ Tags/ Zweige/ ... Büro/ Tabelle/ trunk/ tags/ branches/

Der Grund ist einfach, dass seine unpraktisch ein komplettes Projekt Satz zu markieren, wenn man nur eine bestimmte Untergruppe markieren möchte.

Nehmen wir ein Beispiel: Wenn Projekt-1 von moduleA v1.1 und moduleB v2.3 abhängt, möchte ich nicht, dass das neuere ModulA v2.x in den Tags erscheint. Tatsächlich würde ich, wenn ich einige Tage/Wochen/Monate später zu dieser getaggten Version zurückkomme, gezwungen sein, den Bündeldeskriptor in der markierten Version von Projekt-1 zu öffnen, um die tatsächlich benötigte Version von moduleA zu lesen.

Darüber hinaus, wenn ich eine spezifische Sicherung der Quellen dieser Veröffentlichung auf eine CD machen muss, möchte ich nur dieses Tag exportieren, ohne Hunderte von Megabyte von nicht verwandten Sachen herunterladen.

Es war nur meine zwei Cent.