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.

[Bernhard Geyer]

Zitat:

Zitat von DevLinus (Beitrag 1376202)

Das Erzeugen dauert auf meinen Rechner meist 6 Minuten. Mit Branch wechseln dauert es meist 20-30 Minuten bis man weiter arbeiten kann.

Die Zeiten sind für 3 Mio. Quellcodezeilen relativ hoch?
Könnt ihr bei euren Virenscanner *.pas, *.dfm und *.dcu-Dateien von der Prüfung ausnehmen lassen.?

[himitsu]

Mit Eurekalog geht die CompileTime locker um das Dreifache hoch.

Die großen Fremdbibliotheken ala FastReport kompilieren schnell (ohne Eurekalog)
und unsere eigenen kleineren DLL/BPL/EXE brauchen dagegen mit Eurekalog im Finalbuilder ewig.

Aber OK, knapp 70 BPL/DLL/EXE und bissl weiterer Kleinkram laufen in knapp 5 Minuten durch den FinalBuilder. (7-8 mit allen Fremdbibliotheken)
3-3,5 Minuten ohne Eurekalog
auf SSD, 12 Kerne, 64 GB RAM (meistens 30 GB frei)
alle DLL, EXE und paar BPL multithreaded, also mehrere Compiler parallel

Dagegen waren aber (damals) auch erstmal 10-30 Minuten auschecken, wenn man mal schnell eine bestimmte ältere Version zum Fehlersuchen/Bugfixing/Mergen/... brauchte.

[jaenicke]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1376214)

Könnt ihr bei euren Virenscanner *.pas, *.dfm und *.dcu-Dateien von der Prüfung ausnehmen lassen.?

Vor allem: Welcher ist es denn?

Ich habe die Erfahrung gemacht, dass es da enorme Unterschiede gibt. AVG verlangsamt den Kompiliervorgang z.B. deutlich, während es mit Norton kaum Unterschiede zu ohne gibt.

[DevLinus]

Das Verzeichnis wo die Sourcen drin liegen sind vom Virenscanner ausgeschlossen.

[TiGü]

Zitat:

Zitat von DevLinus (Beitrag 1376328)

Das Verzeichnis wo die Sourcen drin liegen sind vom Virenscanner ausgeschlossen.

Auch jene Verzeichnisse, wo Delphi reinschreibt? DCU, MAP, RSM, TDS, EXE, DLL etc. pp.

[DevLinus]

Zitat:

Zitat von TiGü (Beitrag 1376332)

Zitat:

Zitat von DevLinus (Beitrag 1376328)

Das Verzeichnis wo die Sourcen drin liegen sind vom Virenscanner ausgeschlossen.

Auch jene Verzeichnisse, wo Delphi reinschreibt? DCU, MAP, RSM, TDS, EXE, DLL etc. pp.

Ja das auch. Kann es dran liegen das wir die ganzen Sourcen via Suchpfade eingebunden haben?

[TiGü]

Zitat:

Zitat von DevLinus (Beitrag 1376343)

Ja das auch. Kann es dran liegen das wir die ganzen Sourcen via Suchpfade eingebunden haben?

Ja! So wird alles mitkompiliert, was eigentlich unnötig ist.

[jaenicke]

Zitat:

Zitat von TiGü (Beitrag 1376358)

Zitat:

Zitat von DevLinus (Beitrag 1376343)

Ja das auch. Kann es dran liegen das wir die ganzen Sourcen via Suchpfade eingebunden haben?

Ja! So wird alles mitkompiliert, was eigentlich unnötig ist.

Nein, das passiert nur, wenn die Pfade im Bibliothekspfad enthalten sind.
Der Suchpfad ist nur für den Debugger um beim Debuggen die Quelltexte zu finden.

In den Projektoptionen ist leider der Bibliothekspfad fälschlicherweise als Suchpfad bezeichnet.

[TiGü]

Zitat:

Zitat von jaenicke (Beitrag 1376366)

In den Projektoptionen ist leider der Bibliothekspfad fälschlicherweise als Suchpfad bezeichnet.

Eben, und ich vermute das DevLinus das meint und es so bei ihm vorliegt.

Darum sollte man seine IDE auch als deutscher/französischer/japanischer Entwickler auf englisch stellen.
Dann hat man a) solche Probleme nicht und b) kann viel besser im Internet nach Problemen suchen, wenn man eins mit der IDE hat.

[DevLinus]

Ich meine den hier.

[jaenicke]

Das ist wie TiGü schon vermutet hat in der Tat in Wirklichkeit der Bibliothekspfad.

Wir benutzen stattdessen den globalen Bibliothekspfad, in dem allerdings fast nur ein Pfad zusätzlich drin ist. Dorthin kompiliert das Komponenten/Unit-Buildskript alle Units und kopiert auch die notwendigen .inc Dateien usw. vorher dorthin.
Dadurch ging die Kompilierzeit auch herunter, weil nicht mehr an so vielen Stellen nach den Dateien gesucht werden muss.

[freimatz]

Zitat:

Zitat von himitsu (Beitrag 1376199)

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.

Nein, nie, niemals:!: das tut man nicht.
Wir haben hier im allgemeinen mehrere Ordner mit je einem working copy, so dass wir mehrere branches bearbeiten können. Diese Ordner werden mit subst auf einen Buchstaben gemappt. Ein Wechsel sind bei mir vier Klicks:
- Delphi beenden
- Zwei Tasten für Laufwerk ummappen
- Delphi starten
Wenn ihr wirklich das repo aufteilen wollt dann schaut mal git submodule an.

[Sherlock]

Zitat:

Zitat von freimatz (Beitrag 1376636)

Wenn ihr wirklich das repo aufteilen wollt dann schaut mal git submodule an.

Womit wir wieder bei meinem, genüßlich ignorierten, Vorschlag wären. ;)

Sherlock

[freimatz]

Ich habe den schon gesehen, dachte aber wegen "Subrepository (git Nomenklatur ist mir grad nicht geläufig)" schreib ich das nochmals explizit hin.

[Sherlock]

Zitat:

Zitat von freimatz (Beitrag 1376662)

Ich habe den schon gesehen, dachte aber wegen "Subrepository (git Nomenklatur ist mir grad nicht geläufig)" schreib ich das nochmals explizit hin.

Das sollte beileibe kein Vorwurf sein. Ich fand nur, daß der Thread etwas abhob und vom Thema abkam und mit Deinem Beitrag wieder gelandet ist ;)

Sherlock

[DevLinus]

Ich versuche jetzt gerade das Repository aufzuteilen. Nun folgendes Problem.
Ich habe ein neues Projekt erstellt damit ich die ganzen Suchpfade und so raus habe. Anschließend habe ich die Pfade wo die DCU Dateien liegen als Suchpfad eingefügt und die Units zum Projekt hinzugefügt. Jetzt bekomme ich leider für alle Units die Meldung "[dcc32 Fataler Fehler] UnitName.pas(54): F2051 Unit UnitName wurde mit einer unterschiedlichen Version von UnitName.TKlassenname compiliert". Die DCU's sind aber gerade vorher von mir erzeugt worden. Wenn ich dann den Pfad der Unit als Suchpfad hinzufüge meckert er für diese Natürlich nicht mehr. Aber die nächste Unit macht Probleme. Ich denke mal das wird solange weiter gehen bis ich wieder alle Suchpfade drin habe.

Hat jemand eine Idee was ich falsch mache?

[jaenicke]

Welche Units hast du zum Projekt hinzugefügt? Dort gehören nur die rein, die du nicht per .dcu einbinden willst.

[DevLinus]

Zitat:

Zitat von jaenicke (Beitrag 1377040)

Welche Units hast du zum Projekt hinzugefügt? Dort gehören nur die rein, die du nicht per .dcu einbinden willst.

Jetzt habe jetzt alle Units suchpfade wieder raus und nur noch die DCU suchpfade drin. Bekomme aber die Meldung das sie mit unterschiedlichen Versionen erstellt wurde. Die DCU's habe ich gerade aber mit den aktuellen Sourcen erstellt.

[DevLinus]

Ich schreibe nochmal was ich genau gemacht habe.
Ich habe das alte Projekt kompiliert. Anschließend eine DCU rausgelöscht. Die Unit zu der gelöschten DCU habe ich zu meinem Blanken Projekt hinzugefügt. Anschließend habe ich die Pfade der DCU's hinzugefügt. Nun bekomme ich die Meldung.
[dcc32 Fataler Fehler] UnitName.pas(8): F2051 Unit UnitName wurde mit einer unterschiedlichen Version von UnitName.Klassenname compiliert

[jaenicke]

Der Punkt ist, dass keine der nur in kompilierten Versionen vorliegenden Units eine Unit referenzieren darf, die du in Quelltextform eingebunden hast. Denn die als Quelltext eingebundene Unit kompilierst du ja mit dem Projekt dann neu, die nur kompiliert vorliegende Version aber nicht.

Daher ist dann die kompiliert vorliegende Version älter als die gerade neu kompilierte eingebundene Unit.
Und deshalb wurde die bereits vorkompilierte Unit mit einer anderen Version der nun neu kompilierten Unit kompiliert.

Deshalb haben wir auch zwischen gemeinsamen Units und Projektunits getrennt. Die Projektunits dürfen beide einbinden, die gemeinsamen Units nur andere gemeinsame Units. Alle gemeinsamen Units werden durch ein Package vorkompiliert.

[DevLinus]

Zitat:

Zitat von jaenicke (Beitrag 1377055)

Der Punkt ist, dass keine der nur in kompilierten Versionen vorliegenden Units eine Unit referenzieren darf, die du in Quelltextform eingebunden hast. Denn die als Quelltext eingebundene Unit kompilierst du ja mit dem Projekt dann neu, die nur kompiliert vorliegende Version aber nicht.

Daher ist dann die kompiliert vorliegende Version älter als die gerade neu kompilierte eingebundene Unit.
Und deshalb wurde die bereits vorkompilierte Unit mit einer anderen Version der nun neu kompilierten Unit kompiliert.

Deshalb haben wir auch zwischen gemeinsamen Units und Projektunits getrennt. Die Projektunits dürfen beide einbinden, die gemeinsamen Units nur andere gemeinsame Units. Alle gemeinsamen Units werden durch ein Package vorkompiliert.

Ich habe jetzt test weise alle Units raus gehauen. Eine neue Unit angelegt mit einen Namen der sonst nicht existiert Angelegt und alles Uses rein gemacht. Bekomme dann aber immer noch die gleiche Meldung. Die Units aus dem Programm die ich Verwende werden in den anderen Sourcen auch nicht verwendet.

[DevLinus]

Zitat:

Zitat von jaenicke (Beitrag 1377055)

Der Punkt ist, dass keine der nur in kompilierten Versionen vorliegenden Units eine Unit referenzieren darf, die du in Quelltextform eingebunden hast. Denn die als Quelltext eingebundene Unit kompilierst du ja mit dem Projekt dann neu, die nur kompiliert vorliegende Version aber nicht.

Daher ist dann die kompiliert vorliegende Version älter als die gerade neu kompilierte eingebundene Unit.
Und deshalb wurde die bereits vorkompilierte Unit mit einer anderen Version der nun neu kompilierten Unit kompiliert.

Deshalb haben wir auch zwischen gemeinsamen Units und Projektunits getrennt. Die Projektunits dürfen beide einbinden, die gemeinsamen Units nur andere gemeinsame Units. Alle gemeinsamen Units werden durch ein Package vorkompiliert.

Die Units von dem Projekt sind in den Compilierten Sourcen eigentlich nicht eingebunden. Vor allem die Unit die Aufläuft referenziert zu 100 % auf keiner dieser Units.

[jaenicke]

Such am besten mal auf der Festplatte überall nach den beiden beteiligten Units als kompilierte Variante (.dcu). Vielleicht liegen da ja noch Duplikate irgendwo. (Dafür eignet sich z.B. Everything sehr gut.)

[himitsu]

Manchmal wäre es halt schön, wenn der Compiler 'ne Liste ausgeben würde, wo alle von ihm genutzten Dateien drin stehen, samt der Pfade, damit man sehen kann, was er wirklich nutzt, vorallem bei solchen Fehlern.

[Sherlock]

Bin ich froh, daß ich es einfach nur einfach und nicht elegant oder so gelöst habe. Ich erzeuge meine Projekte immer komplett neu, und kann dennoch währenddessen die Luft anhalten, korrekt versioniert wird es auch noch. Aber viele Wege führen nach Rom, manche mehr, manche weniger steinig.

Sherlock

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1377096)

Manchmal wäre es halt schön, wenn der Compiler 'ne Liste ausgeben würde, wo alle von ihm genutzten Dateien drin stehen, samt der Pfade, damit man sehen kann, was er wirklich nutzt, vorallem bei solchen Fehlern.

Dafür gibt es ja den Process Monitor. Im Zweifelsfall schaue ich damit nach.