Wie granular sind Ihre SVN-"Projekte": ein großes Projekt mit mehreren verwandten Anwendungen oder ein "Projekt" pro Anwendung?

Question

Ich definiere ein Projekt als ein SVN-Verzeichnis, das Stamm, Zweige und Unterverzeichnisse mit Tags enthält.

Nach welchen Kriterien entscheiden Sie, wann Sie ein Projekt in zwei Projekte aufteilen oder mehrere Projekte zu einem zusammenfassen? - Eine App pro "Projekt" mit einem gemeinsamen Projekt für gemeinsame Quellen und Ressourcen? - Ein großes "Projekt" mit allen Quellen und Ressourcen für die App?

Ein einzelnes Projekt oder mehrere Projekte haben beide ihre Vor- und Nachteile. Wir tendieren eher zu einem Einzelprojekt und ich versuche herauszufinden, ob das der richtige Ansatz ist.

Geteilte Projekte ermöglichen eine bessere Kontrolle darüber, wie die verschiedenen Teile der Suite eine Änderung aufnehmen. Die gemeinsame Bibliothek kann versioniert werden, und verschiedene Anwendungen können sich für die Verwendung einer bestimmten Version entscheiden (Maven-Dep-Management-Ansatz).

Geteilte Projekte schaffen auch mehrere Klassenhierarchien, was den Code insgesamt schwerer verständlich macht und möglicherweise zu Codeduplikationen führt. Ich würde davon ausgehen, dass eine angemessene Gestaltung der Gesamtstruktur und der Beziehungen zwischen den Komponenten der Schlüssel zur Bewältigung dieser Kosten ist.

Ein einheitlicher Projektansatz erleichtert dem Entwickler die Einrichtung eines Arbeitsbereichs und bietet eine einheitliche Klassenhierarchie. Dies ist ein zweischneidiges Schwert, da der Entwickler mit viel mehr Informationen konfrontiert wird (zu viele Klassen, um sie zu verstehen).

Wenn Sie also zu entscheiden versuchen, wo Sie kombinieren und wo Sie trennen sollten, welche Faustregeln verwenden Sie dann?

Answer 1

Wachsen Sie biologisch. Voroptimierung ist die Wurzel allen Übels, sagte Dijkstra einmal. Behalten Sie auch YANGI (you ain't gonna need it) im Hinterkopf.

Jede Anwendung erhält ihren eigenen Ordner mit trunk/tag/branches. Wenn ein Projekt innerhalb einer Anwendung sehr groß wird, wird es in einen eigenen Ordner verschoben und kann zur Bauzeit mit der Anwendung verknüpft werden (oder sogar mit svn:externals).

Wenn Ihre Projektanforderungen jedoch darin bestehen, eine komplexe Anwendung zu entwickeln, die von 10 Entwicklern geschrieben wurde, und Sie der Gatekeeper oder Build-Master sind, können Sie komplexere Alternativen in Betracht ziehen.

Answer 2

Behalten Sie separate SVN-Repositories für separate Projekte. Das letzte, was Sie wollen, ist eine Tag der Verschmelzung

Answer 3

Vielleicht möchten Sie sich informieren über Subversion Revisionsnummer über mehrere Projekte hinweg .

Answer 4

Danke für den Beitrag. Ich werde mich nicht für eine Antwort entscheiden, weil ich denke, dass alle Antworten wertvolle Punkte enthalten. Die Vermeidung einer verfrühten Optimierung scheint der Schlüssel zu sein, ebenso wie das Layout vorerst so einfach wie möglich zu halten. Wir sind dabei, die Anwendungen in einem einzigen Projekt zusammenzufassen, da wir in 90 % der Fälle ALLE zusammen veröffentlichen. Daher scheint es nicht sinnvoll zu sein, die Dinge mit einer Anwendung pro Projekt zu verkomplizieren. Selbst wenn wir auf Maven umsteigen, ist es wahrscheinlich, dass alle Maven-Artefakte für eine bestimmte Version aus demselben Zweig stammen werden. Wir können dies später immer noch ändern, wenn es nötig ist, indem wir die SVN-Historie und Fisheye verwenden, um uns zu beruhigen.

Wir werden das Layout des Quelltextes genauso umgestalten wie den Quelltext. Wenn ein Projekt aus Sicht des Umfangs und der Abhängigkeiten zu "stinken" beginnt, werden wir es auflösen, aber nicht vorher. Ich werde wahrscheinlich den Umfang in Zeit und nicht den Umfang in Raum verwenden: Zeit zum Bauen und Testen, Zeit zum Auschecken. Wenn ich einen 1GB-Baum habe, den ich in < 10 Minuten auschecken und in < 30 Minuten bauen/testen kann, brauche ich ihn nicht wirklich aufzuteilen, es sei denn, ich muss Teile davon häufig veröffentlichen.

Also, danke für den Beitrag. Sie waren wirklich hilfreich, um die Frage für mein Team zu formulieren und die Optionen zu bewerten.

Answer 5

Es gibt hier keine "gute" Antwort, aber ich denke, es sollte ein Unterschied gemacht werden zwischen SVN-Repos, die 1 oder 2 Projekte enthalten, und anderen, die 100 enthalten.

Ich verwalte ein SVN-Repository, das von VSS migriert wurde. Es enthält mehrere hundert "Projekte", von denen keines nach der Stamm-/Zweig-/Tag-Struktur organisiert ist (tatsächlich halte ich diese Struktur für wirklich unnötig und wenig hilfreich, nachdem ich SVN eine Zeit lang benutzt habe; es ist sicherlich nicht hilfreich, wenn man 2 oder 3 Projekte als eine einzige Änderung kennzeichnen muss).

Wir unterhalten ein Projektverzeichnis für unsere gesamte gewartete Software, darunter haben wir Unterverzeichnisse für die Konfiguration und ein weiteres für den Quellcode. Darunter haben wir Versionsnummern für die Produkte - wir werfen also das Konzept des Stammes über Bord, wir haben nur Tag-Verzeichnisse - die höchste Nummer ist der Stamm (wir müssen dies tun, da wir mehrere Versionen der Projekte gleichzeitig unterstützen müssen). Das Zusammenführen erfolgt nach Bedarf, wenn ich also einen Fehler in Projekt A, Version 3.0, aktualisiere, führe ich diese Änderungen in Version 4.0 und v5.0 zusammen.

Wenn ich ein Repo mit nur 1 oder 2 Projekten machen würde, wäre ich vielleicht versucht, die Branch/Tag-Struktur beizubehalten, aber auf der anderen Seite würde ich wahrscheinlich die Verzeichnisse explizit im Hauptbaum belassen (vorausgesetzt, ich habe nicht oft genug veröffentlicht, um regelmäßig zu taggen) (Ich verwende übrigens die Revisionsnummer als "Tag" und speichere dort Binärdateien. Wenn ich also eine bestimmte alte Revision benötige, kann ich das richtige Binary aus dem Log holen)

Es ist überraschend einfach zu verwalten, wenn man bedenkt, dass ich ein 10Gb Repo mit einer revnum derzeit über 300.000 mit viel alten Code in es als auch neuere haben. Ich würde die Struktur anderen empfehlen und werde sie wieder verwenden.

Ein weiterer Grund, warum tags dir für uns nicht funktionieren würde, ist übrigens, dass wir jedes Mal, wenn es einen Bug oder eine Änderungsanfrage gibt, egal wie winzig, veröffentlichen. Unser Tags-Verzeichnis wäre nach einer Weile unüberschaubar, deshalb verwenden wir die Revnum als Tag - wir können es mit dem Bug-Tracker verknüpfen, um es auch besser lesbar zu halten.

Grob zusammengefasst haben wir also eine Verzeichnisstruktur wie diese, wobei v1 und v2 Produktversionen sind:

maint/source/v1.0/projectA
maint/source/v1.0/projectB
maint/source/v2.0/projectA
maint/source/v2.0/projectB
etc

Natürlich könnten wir auch ein Zweigverzeichnis unter "source" und einen Zweig/Tag unter jedes Unterprojekt legen, aber das würde schwierig werden, wenn wir 2 Unterprojekte als eine einzige Änderungsanfrage freigeben müssten (was wir ziemlich oft tun). Ein Tag-Unterverzeichnis unter dem Source-Verzeichnis anzulegen, würde bedeuten, dass wir alles taggen, auch wenn nur ein einziges Unterprojekt geändert wurde (das passt nicht zu unserer Anforderung, jedes Unterprojekt einzeln zu verfolgen)