Anzahl an Repositories bei stark verwandten Projekten und Library

[Der schöne Günther]

In den Weiten des Internets finde ich keine eindeutiges Dogma, ob generell ein Repository oder mehrere haben sollte. Klar, kommt ja auf die Umstände an.

Ich suche Rat. Für meine Situation. Die da ist:

• Die ganze Software hier kümmert sich zu 90% um sehr fachspezifische Geschehnisse. Thematisch sind alle stark verwandt
• Weswegen sich die Projekte fast alle Interfaces, oft auch viele Implementationen teilen können
• Der domänenspezifische und trotzdem wiederverwendbare Code ist bislang nur teilweise in eine zentrale Library gewandert
• Ebenso existiert natürlich eine zentrale Library für allgemeingültige Dinge wie Hilfsklassen für Zeit/Datum, VCL-Controls usw.
• Es ist kein riesiger Konzern, wir haben also weder dutzende Projekte noch hunderte Programmierer

Meine konkrete Frage:

1) Was wäre euer Rat zur Anzahl der Repositories? Alles in eins? Ein Repo für Projekte, eins für Libraries? Jedes Projekt trotzdem eigenes Repo?

2) Ist man da mit SVN noch auf der richtigen Seite oder bringt verteilte Versionsverwaltung (von der ich null Ahnung habe) hier eine Heilslösung?

[himitsu]

Wir haben hier alles in einem Repo. (auch SVN)
Nja, man hat immer alles zusammen, vorallem wenn man auch alte Versionen pflegt.

Wenn man mehrere Repositories verwendent, dann sollte/muß man die abhängigen Repositories schön Versionieren, damit auch die alten Revisionen Versionen des Hauptprojektes, bzw. andere Branches noch die passenden Bibliotheken findet.

Man kann in ein Repository auch ein/mehrere andere Repository als Unterverzeichnisse reinverlinken, welche dann automatisch mit aktualisiert werden.
Beim Auschecken, hat man da aber das selbe Problem, wie wenn es nur ein Repo gäbe.
Je nach Größe des Projektes kann das Repository Verzeichnis schonmal recht groß werden. (viel Speicherplatz)
Wenn man diese nicht direkt verlinkt, dann würde man ja nur den Speicher des Hauptrepositories mehrfach benötigen und eventuell ein paar gemeinsam genutzte Verzeichisse für die aktuell genutzten Versionen der Bibliotheken.




Bei uns sind das knapp 1,5 GB (inkl .svn-Verzeichnis, also etwa 620 MB) für einen ausgecheckten Branch.
Effektiv sind die Quellcodes des Hauptprojektes aber nur knapp 30 MB.

Bei mehreren Entwicklern und mehreren Branches pro Entwickler läppert sich das ganz schön und beim Auschecken eines neuen Branches braucht das schon mehrere Minuten,
was sich durch Abtrennen von Fremdkomponenten und Co. bestimmt besser gemacht hätte.




Und wie Phoenix es so schön erklärte, kannst du bei getrennten Repositories die abgetrennten Teile in anderen Projekten schön wiederverwenden und hast dann nicht alles doppelt und dreifach.

[Phoenix]

Welche Versionsverwaltung Du nimmst ist im Prinzip je nach Gusto.

Verteilt hat Geschwindigkeitsvorteile wenn man an verteilten Standorten arbeitet, da nicht jede Operation wie branchen oder mergen zum Server muss sondern lokal passieren kann. Und branchen und mergen funktioniert einfach etwas besser, weil die verteilte Versionierung mehr Informationen mit sich trägt. Ich präferiere Git, aber grundsätzlich funktioniert das aber alles auch noch mit SVN.

Meine persönliche Präferenz, würden wir hier nicht von Delphi sondern z.B. von .NET, Java oder JavaScript (Node) reden wäre, jedes Projekt in ein eigenes Repo, einen automatisierten Build- und vor allem auch einen automatisierten Release-Prozess implementieren, und dann von den anderen Projekten aus nur noch die Kompilate bzw. die Packages (NuGet, Maven, NPM) einbinden. Als Build-Server bietet sich z.B. erstmal die kostenlose Version von TeamCity an.

Mit Delphi lassen sich Paket-Abhängigkeiten leider nicht so einfach verwalten, weswegen sich das prinzipiell eher schwierig gestalten würde, aber auch hier kann man Abhilfe schaffen:

Auch hier wieder alle Projekte in ihr eigenes Repository. Zusätzlich ein Repository, in dem nur gesharte Kompilate versioniert liegen (also alle Libraries und alle Komponenten-Packages). Diese könnten dann wieder automatisiert erstellt und aktualisiert werden.

Man checkt also das Projekt aus, an dem man arbeitet, und die fertigen Libraries aus dem zentralen Binary-Repo (als Ersatz für eine Package-Quelle).
Man kann hier dann auch per Git Sub-Repository bzw. SVN-Externals die fertig kompilierten Abhängigkeiten direkt im Repository referenzieren und gleichzeitig mit auschecken lassen. Dann ist das kein manueller Schritt mehr.

Wenn man sich dann noch an Semantic Versioning hält, dann kann man die Abhängigkeiten auch recht einfach verwalten und weiss ob man bei Updates aufpassen muss oder nicht.

Wir schmeissen bei Smarthouse gerade 5 gesharte Libs/Produkte mit einem 3-Mann Team (okay, wir waren auch Zeitweise mal bis zu 5), und die Ergebnisse die wir da produzieren werden von vielen Teams (insgesamt ca. 60-80 andere Kollegen) genutzt. Und das haben wir auch mit SVN und Externals gemacht, als Git und NuGet noch nicht so gehyped wurde

[Sherlock]

Wir (fünf Entwickler) handhaben mehr als ein Dutzend Produkte mit reichlich gesharten Units/Komponenten mit genau zwei Tools (Windows mal ausgenommen): Delphi und TortoiseHg (Ok, das sind dann wohl eher zwei in einem). Jedes Produkt hat sein eigenes Repo, die gesharten Units/Komponenten liegen in einem eigenen Repo, das als Subrepo hinzugefügt werden kann. Damit ist dann auch der Versionsstand der gesharten Dinge für eine bestimmte Produktversion gesichert/festgelegt.

Das Arbeiten geht zügig und einfach und man muss nicht allzuviel lernen und was meine Kollegen lieben: man muss sich nicht auf zu viel unkontrollierbares verlassen. Die Unwägbarkeiten von Delphi verursachen schon genug graue Haare.

Sherlock

[alda]

Was ich bei mehreren Repositorys relativ nervig finde ist die Anpassung der Suchpfade in deinem Projekt aus Repository A, welches mit Komponenten aus Repository B, C und D arbeitet. Erzeugst Du Einen Branch von Repository A, müsstest Du theoretisch auch Branches aller anderen Repositories anlegen und in Deinem Projekt aus Repository A entsprechend die Suchpfade anpassen (oder die Umgebungsvariablen) und musst alle Änderungen an den Repositories entsprechend auch immer separant mergen und committen.

Wir (8 Entwickler) haben aus diesem (und auch anderen) Gründen alles in einen Topf geworfen und hatten anschließend das angesprochene Problem von himitsu, dass ein SVN Checkout durchaus 10 Minuten dauert.

Ein meines Erachtens durchaus wichtiger Punkt bei dieser Entscheidung ist auch schon das einzusetzende Versionierungssystem, da Du z.B. in GIT diesbezüglich andere Möglichkeiten hast (Stichwort submodule/subtree, das gilt es gemäß Deinen Anforderungen zu evaluieren) was die Aufteilung der Projekte angeht. Für unser Riesenprojekt ist das arbeiten mit GIT (zumindest für mich) wesentlich angenehmer und vorallem schneller geworden (gerade dank lokalen Branches).