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

Wir haben alle Projekte, die zu einer einzigen Anwendung gehören, in einem SVN Rep zusammengefasst, um die Wartung zu vereinfachen, die Codebasis der Anwendung in einem einzigen Repository zu zentralisieren und die Abhängigkeiten zwischen den verschiedenen Ressourcen der Anwendung zu verwalten.

wir kategorisieren unsere ressourcen in der regel in verschiedene ordner innerhalb von trunk. diese kategorisierung basiert in erster linie auf der funktionalen/modularen gruppierung oder der schichtweisen gruppierung [DAL, BLL, GUI, etc.]. das liegt ganz daran, wie sie den code strukturiert haben. Ich hoffe, das hilft.

Answer 2

El SVN-Buch hat eine gute Diskussion über beide Ansätze.

Letztendlich würde ich mich für das entscheiden, was sich für die Nutzer des Repository am natürlichsten anfühlt.

Ich persönlich bevorzuge einen einzigen SVN-Stamm/Tags/Zweige mit allen meinen eigentlichen Code-Projekten in ihren eigenen Ordnern innerhalb dieser.

Bei einer größeren Code-Basis (ich habe nur 3-4 kleine Projekte verwaltet, die Teil einer einzigen Lösung waren) würde ich jedoch einen Wechsel zu einem Split-Ansatz in Betracht ziehen.

Answer 3

Ich verwende sowohl getrennte Projekte als auch kombinierte Projekte, je nach Projektgröße. Bei unseren großen Projekten befindet sich jedes Projekt in einem separaten Repository und verfügt über unabhängige Build- und Bereitstellungsverfahren. Für unsere kleineren Projekte haben wir ein "Tools"-Repository, das sie enthält, wobei jedes Unterprojekt ein Unterverzeichnis des Root-Repositorys ist.

Ich verwalte auch ein "persönliches" Repository, in dem Leute ihre Testprogramme, einmalige Hilfsprogramme oder andere Dinge speichern können, die von einer Versionskontrolle und zentralisierten Backups profitieren könnten, aber nicht in ein unabhängiges Projekt gehören.

Answer 4

Ich verwende separate Projekte und kombiniere sie zu einer Lösung durch svn:externals.

Answer 5

Eine Anwendung / ein Modul, das unabhängig pro Projekt eingesetzt wird. Die Verwendung eines einzigen Projekts erschwert die Einführung von Release-Zyklen, wenn Sie jemals herausfinden, dass Sie ein Maven-ähnliches Abhängigkeitsmanagement benötigen, bei dem ein Modul von stabilen Implementierungen anderer Module abhängt. Es kann auch dazu führen, dass Leute einfach zufälligen, nützlich aussehenden Code aus anderen Anwendungen direkt verwenden, anstatt ihn zu berücksichtigen, um den Abhängigkeitsgraphen vernünftig (tm) zu halten.

Sie sollten Integrationstests unter Verwendung geeigneter Testsuiten und CI-Praktiken an klar definierten Stellen durchführen und sich nicht darauf verlassen, dass die Hälfte Ihres Codes plötzlich ausfällt, wenn ein Teil nicht funktioniert.

Ein weiteres Problem mit einem einzigen Uber-Projekt ist, dass es für git-svn-Benutzer, die nur an einem einzigen Modul arbeiten, ziemlich lästig ist.