Wann sollte ein multi-Modul-Projekt, aufgeteilt in separate repository Bäume?

Question

Derzeit haben wir ein Projekt mit einem standard-subversion-repository-layout:

./trunk
./Zweige
./tags

Jedoch, wie wir uns bewegen, die Straße runter von OSGi und ein Modulares Projekt, haben wir am Ende mit:

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

Die 'build' ist noch Recht monolithischen, dass es kompiliert alle Module in der Reihenfolge, aber ich fange an zu Fragen, sollten wir umgestalten build/repository zu etwas mehr wie:

./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 jedes Modul Gebäude selbst und Speicherung Ihrer Binärdatei in ein repository (maven, ivy oder einen anderen Weg des subversion-Projektarchivs selbst).

Gibt es Richtlinien oder "best-practices" über die Projekt-layouts sobald einer geht noch modular?

Answer 1

Subversion Buch enthält zwei Abschnitte auf:

• Repository Layout
• Planen Sie Ihre Repository-Organisation

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

Die kurze Antwort, aber:während Ihre Laufleistung variieren (jede situation ist individuell), Ihr /bundle/<project>/(trunk|tags|branches) Schema ist Recht Häufig und wird wahrscheinlich gut funktionieren für Sie.

Answer 2

Dies ist sehr viel bis zu den persönlichen Vorlieben, aber ich finde die folgende Struktur geeignet für große Projekte, die 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 auch oft verwendet wird die Struktur in großen repositories mit vielen Projekten, da halten alle Projekte in der gleichen repository macht cross-referencing Projekte und gemeinsame Nutzung von code zwischen Ihnen—mit Geschichte—zu erleichtern.

Ich mag die Struktur mit root trunk, tags und branches von Ordnern vom start, weil in meiner Erfahrung (mit großen Repositorys, in der es viele Projekte, viele sub-Projekte und Module werden nie getrennte tags oder Zweige, so es ist keine Notwendigkeit zu schaffen, die Ordner-Struktur für Sie.Es macht es auch leichter für die Entwickler, um check out den gesamten Stamm des Repositorys und nicht alle tags und Zweige (die Sie nicht brauchen, die meisten der Zeit).

Ich denke, das ist eine Frage der Projekt-oder Unternehmens-Politik, obwohl.Wenn Sie ein repository für jedes Projekt oder einem bestimmten Entwickler ist wahrscheinlich nur die Arbeit an einem Projekt in das repository zu einer Zeit, von den tief verwurzelten Stamm kann nicht so viel Sinn.

Answer 3

Nur meine zwei Cent...

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

Der Auszug Referenzen die folgende Struktur :/ trunk/ calc/ Kalender/ Arbeitsblatt/ ... tags/ calc/ Kalender/ Arbeitsblatt/ ... branches/ calc/ Kalender/ Arbeitsblatt/

"Es gibt nichts besonders falsch an dieser Anordnung, aber es kann oder kann nicht scheinen, als intuitiv für Ihre Benutzer.Vor allem in großen, multi-Projekt-Situationen mit vielen Benutzern, die Benutzer dazu neigen kann vertraut werden mit nur ein oder zwei Projekte, die im repository.Aber der Projekte-als-Geschwister-Zweig-tendenziell zu de-betonen Projekt-Individualität und konzentrieren sich auf die gesamte Reihe von Projekten als eine einzige Einheit.Das ist ein Soziales Problem, obwohl.Wir mögen unseren ursprünglich geäußerten Vorschlag aus rein praktischen Erwägungen—es ist einfacher zu Fragen (oder Sie zu verändern, oder migrieren Sie anderswo), in der kompletten Historie eines einzelnen Projektes, wenn es einen einzelnen Pfad im Projektarchiv, das hält die ganze Geschichte—die Vergangenheit, Tags und verzweigte für das Projekt, und nur dieses allein."

Für meine eigene, ich Stimme zu ziemlich stark mit diesem und lieber das folgende layout:/ utils/ calc/ trunk/ tags/ branches/ Kalender/ trunk/ tags/ branches/ ... Büro -/ Arbeitsblatt/ trunk/ tags/ branches/

Der Grund dafür sind schlicht, dass seine unpraktisch-tag ein komplettes Projekt zu setzen, wenn man möchte tag nur eine bestimmte Teilmenge.

Verwenden wir ein Beispiel:Wenn Projekt-1 hängt von moduleA v1.1 und moduleB v2.3, ich nicht wollen, dass neuere moduleA v2.x erscheint in den tags.In der Tat, kommen wieder einige Tage/Wochen/Monate später zu diesem tagged release, ich wäre gezwungen, öffnen Sie das Paket descriptor in die tagged version von project-1 Lesen Sie die version von moduleA tatsächlich erforderlich ist.

Außerdem, wenn ich eine bestimmte backup von diesem release die Quellen auf eine CD zu machen, ich will nur den export mit diesem tag, ohne das herunterladen von Hunderten von Megabyte von unzusammenhängenden Kram.

Es war nur meine zwei Cent.

Answer 4

Ich habe eine ähnliche Frage beantwortet in einem StackOverflow Version Control Structure Frage.Es passt eigentlich noch besser hier denn wir machen die schwere OSGi-Entwicklung und haben viele bundles.Ich muss echo Anders Sandvig Kommentare:halten trunk/tags/branches auf der root-Ebene, da Sie den Zweig nur einen begrenzten Satz von Modulen.Es ist auch nicht zu stören-Module Gebäude individuell.

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