Repository aufteilen GIT

[DevLinus]

Guten Morgen,
gegeben ist ein Repository. Dort sind Zwei Hauptprojekte drin. Die Hauptsoftware und eine weitere Software zum Pflegen der Datenbestände.
Das Datenpflegetool hat leider extrem starke Verbindungen zu der Hauptsoftware. Deswegen werden so gut wie alle Units mit Compiliert.
Das sind mit externen Code knapp 3 Millionen Zeilen Code. Dies dauert natürlich extrem lange zu erzeugen wenn man auf ein Branch wechselt. Da wir mehre Releases haben muss die Abteilung die für die Pflege des Datenbestand zuständig sind öfter den Branch ändern. Da geht an schlechten Tagen gerne mal pro Mitarbeiter mehr als 1 Stunde zeit verloren mit Branch wechselen und neu Erzeugen der Sourcen.

Hat jemand ein Ansatz wie man das Projekt aufteilen könnte? Die Sourcen der Hauptsoftware ändern sich nur einmal die Woche in den Branches wo das Datenpflege Tool entwickelt wird.

[Sherlock]

Ich denke da kämst Du gut mit einem Subrepository (git Nomenklatur ist mir grad nicht geläufig, aber es dürfte klar sein, was ich meine) hin, das alle gemeinsamen Units beinhaltet. Dann aus dem einen alten Repositor zwei machen (pro Projekt eines) und das Subrepository einbinden und es sollte alles so werden, wie Du es Dir vorstellst.

Sherlock

[jaenicke]

Wir haben dafür gemeinsame Units, die in den anderen Projekten eingebunden werden. Aber nicht per Quelltext, sondern per DCU. Sprich wir haben ein Package mit den gemeinsamen Units um diese zu kompilieren und in den Projekten direkt eingebunden nur die projektspezifischen Units.

So können wir die gemeinsamen Units per Buildskript bei Bedarf erzeugen und nur die projektspezifischen werden mit dem Projekt erzeugt.

Ihr könntet nun z.B. schlicht ein Package nehmen, bei dem für die einzelnen Releases mit unterschiedlichen DCU-Ausgabeverzeichnissen gearbeitet wird, je nach Branch. Dann bleiben die unveränderten Units nämlich liegen und es geht deutlich schneller zu kompilieren.
Dann noch ein PostBuild-Skript oder ein Befehl im Buildskript, dass die Units nach dem Kompilieren aus diesem Ausgabeverzeichnis in ein entsprechendes gemeinsames Bibliotheksverzeichnis kopiert (das im Bibliothekspfad eingetragen ist).

Um an den gemeinsamen Units leichter etwas ändern zu können, haben wir aber auch oft *_debug.dproj Projektdateien, in denen auch die gemeinsamen Units in den Projekten eingebunden sind. Mit entsprechend längeren Kompilierzeiten.

[Bernhard Geyer]

Zitat:

Zitat von DevLinus (Beitrag 1376186)

Dies dauert natürlich extrem lange zu erzeugen

Definiere Extrem Lange. 3 Mio Quellcodezeile sollte Delphi in 2 Minuten schaffen.

Zitat:

Zitat von DevLinus (Beitrag 1376186)

wenn man auf ein Branch wechselt.

Ich habe bei mir neben dem HEAD auch den/die letzten Branches auf Platte compilierfähig ausgecheckt liegen.
In der IDE muss ich nur eine Umgebungsvariable umsetzen (alle Suchpfade von 3th-Party-Komponenten/eigen Source basieren darauf).
Ist praktisch kein Aufwand.

[Der schöne Günther]

Wenn das eigentliche Problem die Dauer für das Zweig-Wechseln und Neu-Kompilieren für Zweige A,B,C (z.B.) sind, warum dann nicht einfach mehrmals das Repo drei mal auf der Platte haben, jeweils auf Stand A, B und C? 8-)

[jaenicke]

Ja, mehrfach aus unterschiedlichen Branches nebeneinander ausgescheckt haben wir auch. Aber eben mit unterschiedlichen DCU-Ausgabepfaden.

[himitsu]

Beide Programme mit der selben Delphi-Version?
Wenn nicht, dann muß sowieso jeder alles kompilieren.

Die zweite Anwendung bekommt nur Zugriff auf die vorkompilierten DCU.
PAS maximal im Bibliothekspfad, zum Debuggen, aber lohnt sich nur, wenn die DCUs auch mit Debuginfos kompiliert werden.

Man könnte auch komplett alle gemeinsamen PAS (sie sollten seltener geändert werden) in ein drittes Projekt legen und darüber kompilieren.
Die beiden eigentlichen Programme bekommen dann nur die DCUs, müssen sie niemals neu kompilieren.

Die DCUs sollten dann natürlich mit im GIT liegen
oder in einem externen branch-/versionsabhängigen Verzeichnis, damit beim Branchwechsel direkt die passenden DCUs vorhanden sind.


Wie haben bei uns alle Fremdkomponenten mit im SVN.
Das waren samt SVN-Dateien fast 1,5 GB. und die eigentlichen Programmsourcen nur 80 MB (300 MB kompiliert)
Die Fremdbibliothenken wurden auch auch so schon einzeln kompiliert (eine überspringbare Gruppe im FinalBuilder) und es konnte so entweder alles oder z.B. nur die eigenen EXE/DLL/BPL kompiliert werden. Als weitere Gruppen noch sowas wie Setup erstellen, Hilfe generieren, Delphi einrichten (Femdkomponenten reistrieren und DDevExtensions, IDE-FixPack usw).

Den Teil mit den Fremdkomponenten haben wie letztens auch in ein eigenes Repository ausgelegt (je Eines pro Version) und das Auschecken/Branchwechseln geht jetzt auch viel schneller, da ja nur noch knapp 150MB statt 1,5GB runtergeladen werden müssen, aber als Sub-Repository (Unterverzeichnis) an der alten Stelle verlinkt (Hardlink), um jetzt nicht alles umbauen zu müssen (Pfade überall anpassen/ändern).

[DevLinus]

Danke euch hat mir schon extrem weitergeholfen. Ich werde die Unterschieldichen Optionen am Montag mit meinen Teamleiter besprechen.

Ja zum Glück sind alle aktuellen Releases gerade mit der gleichen Delphi Version.
Das Erzeugen dauert auf meinen Rechner meist 6 Minuten. Mit Branch wechseln dauert es meist 20-30 Minuten bis man weiter arbeiten kann.

[himitsu]

Wenn es zu lange dauert.
http://www.delphipraxis.net/192628-i...y-version.html

Aber 6-20 Minuten geht ja noch.

[DevLinus]

Zitat:

Zitat von himitsu (Beitrag 1376205)

Wenn es zu lange dauert.


Aber 6-20 Minuten geht ja noch.

Wenn mann danach eine lange zeit auf den Branch ist ja. Wir arbeiten aber ziemlich viel auf Zuruf. Da ohne die neuen Daten unsere Datenpfleger nicht weiter arbeiten können. Das heißt das es an einen schlechten Tag vorkommen kann das du drei bis 5 mal hin und her wechselst um ein Routine hinzuzufügen. (Dauert meist nur 30 Minuten) sie zu Entwickeln wenn die Regeln gut definiert sind.