hi wie geht man eigentlich um mit einem Projekt wo es mehrere git repos gibt. Ich errinere mich an ein Projekt der aus knapp 40 einzelne repos bestand. es gab ein tcl script der bei einem release ein git Tag über alle repos gezogen hat. und es gab ein script der alle repos entweder basierend auf ein tag, oder überall den top of the tree gecloned hat. Schreibt man Heutzutage einen eigenen Script, oder gibt es da ein tool? Subrepos kommen für mein usecase nicht in Frage. Wie gehen gitlab/github/bitbucket mit der Thematik um. Danke
:
Verschoben durch Admin
H. R. schrieb: > Schreibt man Heutzutage einen eigenen Script, oder gibt es da ein tool? > Subrepos kommen für mein usecase nicht in Frage. warum genau kommen subrepos nicht in Frage? Bitte beschreibe das Problem sauber und ausführlich genug: wenn man das Problem/Usecase versteht, kann man vielleicht passende Tools vorschlagen. Mit Subrepos kannst Du zumindest die Sache mit dem zentralen Release-Tag sauber lösen. > Wie gehen gitlab/github/bitbucket mit der Thematik um. Mir wäre nicht bewusst daß die einen extra Workflow oder Tool für mehrere gemeinsame Repos, die aber keine subrepos sind, anbieten würden.
Hmm, lass mich das mal zusammenfassen: Du hast in einem Projekt mehrere separate Repos, die zwar nichts mit einander zu tun haben und die auch nicht als "Subrepos"(*) ausgeführt werden sollen, aber trotzdem wie ein großes Repo behandelt werden sollen. Mir wäre dafür nichts bekannt, aber mir erschließt sich auch der Sinn nicht. (*) Was ist damit gemeint? Submodules oder Subtrees? Oder beides?
hi also mein usecase: es gibt 20 Produkte die verschiedene Versionen von irgendwelche Libraries/komponenten verwenden. Auf allen komponenten wirk aktive weiter gearbeitet. Jedes Produkt hat ein eigenes Repo und ein TCL Script was alle Libraries und Ihre Versionen festlegt. Ist das State of the Art?
H. R. schrieb: > Ist das State of the Art? Nein, Bastelskripte sind sicher nicht state of the art. git bietet unter anderem das Feature "submodule" (was die oben erwähnten subrepos sein sollen weiß ich nicht, das gibts im git-Jargon nicht). Mit submodule kannst du Dritt-Repos in dein Repo einbinden (und, ganz wichtig, auf einen spezifischen Commit referenzieren). Da kannst du dich mal einlesen. Ist aber ziemlich fummelig und fehleranfällig wenn man nicht weiß was man tut. Aber besser als deine Skriptsammlung dürfts sein.
:
Bearbeitet durch User
Android/AOSP macht das mit über 500 einzelnen Repositories, welche über ein Python-Programm "repo" verwaltet werden: https://source.android.com/setup/develop/repo
Ich check das gewünscht Szenario immer noch nicht. Ist es: A) Ein Projekt besitzt Abhängigkeiten zu mehreren Bibliotheken (ebenfalls Projekte) und es geht darum diese zu verwalten und einzubinden. B) Es existieren mehrere Projekte die nichts miteinander zu tun haben, die aber halt physikalisch am selben Git-Server liegen. Diese sollen verwaltet werden.
Le X. schrieb: >> Ist das State of the Art? > > Nein, Bastelskripte sind sicher nicht state of the art. Na ja so Bastelskripte sind das nun wieder auch nicht, Wenn ich mir zum Beispiel das Yocto Projekt ansehe, dort werden git repos in den Rezepten auch über ihren Hashwert referenziert in den recipes. Und das von dir präferierte git submodule ist eigentlich auch nur ein Referenzierter Hash in der .gitmodules mit ein paar convenience Funktionen. H. R. schrieb: > Ist das State of the Art? Das Kommt drauf an ;) wenn dein TCL Script wirklich nur die entsprechenden SHA1-HASHs auscheckt vielleicht. H. R. schrieb: > TCL Script was alle Libraries > und Ihre Versionen festlegt Der Teil macht schon eher Zahnschmerzen, was genau heißt für dich "und Ihre Versionen festlegt" die Benötigen Versionen sollten ihrerseits in einen Git sein und nicht über irgenwelche Tags definiert werden und hierfür bringt das git Projekt halt den Mechanismus des submodule mit. H. R. schrieb: > es gibt 20 Produkte die verschiedene Versionen von irgendwelche > Libraries/komponenten verwenden. Auf allen komponenten wirk aktive > weiter gearbeitet. Spätestens hier solltest du ganz laut Buildsystem schreien und nicht versuchen was selbst zu Bastelen, im Embedded Bereich ist gerade Yocto so eine art Industrie Standard. Aber es gibt auch noch ptxdist, e2factory Buildroot und viele andere, meine Empfehlung ist das du dich hier einarbeitetest und nicht versuchst das Rad neu zu erfinden.
Vincent H. schrieb: > Ich check das gewünscht Szenario immer noch nicht. Ist es: > > A) Ein Projekt besitzt Abhängigkeiten zu mehreren Bibliotheken > (ebenfalls Projekte) und es geht darum diese zu verwalten und > einzubinden. > variante A
> Spätestens hier solltest du ganz laut Buildsystem schreien und nicht > versuchen was selbst zu Bastelen, im Embedded Bereich ist gerade Yocto > so eine art Industrie Standard. Aber es gibt auch noch ptxdist, > e2factory Buildroot und viele andere, meine Empfehlung ist das du dich > hier einarbeitetest und nicht versuchst das Rad neu zu erfinden. Hi Was YOCTO angeht: könntest du mir ein link zum git methodik in yocto schicken? ich sehe gerade das ist ein ziemlich grosses Projekt. Oder wonach soll ich innerhalb von YOCTO suchen um drauf zu kommen wie da git verwendet wird?
imonbln schrieb: > im Embedded Bereich ist gerade Yocto > so eine art Industrie Standard. Yocto hat nur einen einzigen Zwweck: Ein bootbares Linux-Image nach eigenem Gusto mit eigenen Komponenten zu bauen, darum dreht sich 99.9995% von dessen Funktionalität, yocto hat nichts damit zu tun irgendwelche git-Repositories besser zu managen als man es auch mit nem simplen Script machen könnte. Ganz im Gegenteil sogar, Yocto bringt praktisch gar nichts mit für sein git Problem, er wird noch mehr scripten müssen als er es jetzt schon tut. Und anscheinend baut er keine Linux-Images sonst würde Yocto schon längst zu seinem Arsenal gehören, also hat er NULL Verwendung für Yocto.
:
Bearbeitet durch User
Niklas G. schrieb: > Android/AOSP macht das mit über 500 einzelnen Repositories, welche über > ein Python-Programm "repo" verwaltet werden: Falls das gerade nicht ganz klar rüberkam - das "repo" Tool kann auch ohne Android benutzt werden (ist sogar in den Ubuntu-Paketquellen) und sollte sich problemlos für eigene Projekte einsetzen lassen. Es ist ein recht stabiles Tool und funktioniert i.A. gut. Das ist ziemlich genau das was gesucht wird! Submodule sind meiner Erfahrung nach nicht so flexibel und skalierbar. Siehe auch: https://www.edureka.co/blog/git-submodules-versus-googles-repo-tool Wobei ich zum Punkt "Hard to reconstruct old versions." sagen muss, dass man auch fixe Versions-Kombinationen definieren kann, indem man entsprechende Manifeste mit Versions-Commits erzeugt. Muss man dann genau so pflegen wie normale git-commits.
H. R. schrieb: > Ich errinere mich an ein Projekt der aus knapp 40 einzelne repos > bestand. es gab ein tcl script der bei einem release ein git Tag über > alle repos gezogen hat. > > und es gab ein script der alle repos entweder basierend auf ein tag, > oder überall den top of the tree gecloned hat. Das halte ich weiterhin für die beste Methode. Vielleicht kann man die Hauptarbeit vom oben erwähnten repo tool machen lassen. Da passiert dann kein versteckter Hokuspokus im Hintergrund und das Script wird simpel und straightforward sein, alles zentral an einer Stelle und einfach zu überblicken. Mit git submodule bekommst Du es auch nicht besser hin, es wird damit nur fummeliger, unübersichtlicher und leichter sich in den Fuß zu schießen und scripten mußt Du da erst recht denn ansonsten verlierst Du die Kontrolle und schießt Dir jeden Tag zweimal in den Fuß bei 40 Untermodulen.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.