git performance unbefriedigend

hustbaer

[Vermutung eines der sich mit git nicht wirklich auskennt]

Kann man bei git nicht auch nur das auschecken was man wirklich braucht?
Das lokale Repo enthält natürlich immer alles, aber man wird doch hoffentlich sowas wie ne Working-Copy eines Unterverzeichnisses machen können?

Dann sollten sich auch die lstat()-Aufrufe in Grenzen halten.

[/Vermutung eines der sich mit git nicht wirklich auskennt]

zwutz

hustbaer schrieb:

Das lokale Repo enthält natürlich immer alles, aber man wird doch hoffentlich sowas wie ne Working-Copy eines Unterverzeichnisses machen können?

Das lokale Repo _ist_ deine Working Copy.

Es gibt aber die Möglichkeit, Module oder Subtrees anzulegen, die du dann auch getrennt verwalten kannst und trotzdem am Ende im gleichen Repo landen. Das hab ich aber bisher noch nie so umfangreich verwendet, dass ich mehr dazu sagen könnte

Bzgl der Performance hatte ich bisher keine Schwierigkeiten (unter Linux). Unser Repo ist aber ein wenig kleiner als 1,6 GB

hustbaer

Nö, das lokale Repo ist das .git Verzeichnis, und die Working-Copy ist eben die Working-Copy.

Wenn ich die Working-Copy lösche, kann ich mit "Revert" immer noch alles zurückholen. Weil es eben im Repo (=.git Verzeichnis) noch vorhanden ist.

hallo zusammen,

erst mall dank für die antworten. also mein os ist centos5.8, dass home directory würd über eine nfs share zur workstation gemountet. ich vermute auch, dass der fileserver, welcher dass home directory hostet zu langsam ist. git status will ich nicht aushebeln. denn ich bin vergesslich und habe ja auch gerade deswegen git eingeführt ;). klar, wenn man drüber nachdenkt, dann ist die überprüferei bei den libs aufwändig aber notwendig. gibt es da noch nen anderen weg? wie verwaltet ihr eure libs?

gruß

hustbaer

OMG leg das Ding auf ein lokales Laufwerk. Natürlich ist es langsam wenn du das "lokale" Repo auf nem Netzlaufwerk liegen hast.

SideWinder

Warum klonst du das Repository nicht vom NFS auf ein lokales Directory und nutzt pull/push um dorthin zu spielen. Ich hoffe ja doch stark, dass ihr nicht alle gemeinsam auf einem gemeinsamen git-Repo am NFS arbeitet nur weil euer CVS/SVN-Workflow so aussah...

MfG SideWinder

hallo zusammen,

das mit dem lokalen repo hab ich auch schon überlegt, aber da weiß ich nicht so richtig. zum einen arbeiten an dem projekt mehrere leute. im moment sind die ganzen build skripte so ausgelegt, dass sie quasi auf $HOME\.... zeigen. wenn ich dies lokal irgendwo hinschiebe, ist es a) bei jedem anders und b) wechsle ich auch oft die maschinen bzw. arbeite remote. mein nfs home habe ich immer, die lokale platte nicht, bzw. nur durch mehrere ssh tunnel. was auch performance und vorallem usability kostet.

klar könnte man es lokal legen und über home nen link legen, aber das bring doch nicht wirklich punkte, oder?

das repo ansich liegt zentral auf einem server. also könnt ich auch direkt nach lokal clonen, den umweg über das nfs, würde ich dann nicht verstehen. origin ist bei uns gemeinsam/zentral. ist dies falsch?

hustbaer

Also jetzt nochmal konkret.
Wie viele Repos (Klone) gibt es?
Und wer arbeitet auf welchem?
Hat jeder seinen eigenen Klon, nur dass die halt alle auf nem File-Server liegen, oder arbeiten alle auf dem selben Klon?

Was die Build-Skripte angeht, die solltest du mMn. sowieso anpassen, also dass der Pfad wo das Repo liegt keine Rolle mehr spielt.

Und was das dauernde Wechseln des Arbeits-PCs angeht...
Entweder du pusht vor jedem PC-Wechsel alle Änderungen, und pullst sie dann auf der nächsten Maschine wieder aus dem zentralen Repo...
Oder du besorgst dir nen Laptop.

hallo zusammen,

erst mal sorry, dass ich mich so lange nicht gemeldet habe. ich war krank und auf dienstreise, da blieb dies hier liegen.

zurück zum thema:

es gibt zwischen 4-6 repos für meinen branch. bei mir auf dem arbeitsrechner ist das "haupt"-repo, dann noch welche bei studenten. da ich ab und an auf testmachinen muss, liegt mein repo im homeverzeichnes, welches ich vom fileserver gemappet bekomme. dies trifft auch auf die repos bei den studenten zu. alle arbeiten auf ihren eigenen repo und pushen zu origin. des weiteren gibt es noch ca. 3 leute, welche auf anderen branchen des selben repos arbeiten.

das build-skript definiert den start punkt, danach ist alles relativ. also im sinne von:

SOURCE_PAHT=$(HOME)\path\to\repo

gibt es da ne bessere idee? ich sehe es gerade nicht.

laptop ist keine alternative, es sei den, du kennst einen mit 8 kernen und 16GB RAM, wo ich ne fette simulation laufen kann, welche so drei, vier tage läuft, wenns doof kommt ;). das pushen und pullen nervt langsam, da git sämtliche bibliotheken beim status mit checkt. da passiert aber max. einmal im halben jahr was. der eigentliche projekt source ist nur ca 60mb. aber die libs und co brauch man um das projekt auf ner nackten machine aufzusetzen. und damit die studenten die richtige version, vorallem alle die gleiche, nehmen, liegen die halt mit im repo. oder gibt es da ne bessere idee? so ist es halt cool: clonen, alles ist da, im simulator einfach neues projekt anlegen, source angeben, build-skript angeben, fertig. nix mit einstellen, kopieren etc.

nen tip?

gruß und so

boost im localen project repo, event. sogar mit allen html und samples, ist vielleicht nicht so optimal.

nachdem boost sich ja nicht so oft ändert und arbeit daran eher selten ist, leg das in ein sub module und *link* es in dein projekt.
dann kann sich das project repo auf die wirklichen project datein konzentrieren ohne sich um tausende andere 3rd party files kümmern zu müssen

schau dir mal das das an, vielleicht hilfts
http://git-scm.com/book/en/Git-Tools-Submodules

nman

sven_ schrieb:

da ich ab und an auf testmachinen muss, liegt mein repo im homeverzeichnes, welches ich vom fileserver gemappet bekomme.

Und genau da liegt das Problem. Git verlässt sich auf sehr sehr schnelle lstat-Aufrufe, die du mit deinem NFS-Server einfach nicht hast.

Die Lösung ist die, lokalen Storage zu verwenden. Dh. du klonst einmal von deinem Git-Server auf die aktuelle Maschine und beim nächsten Mal brauchst du ja keinen vollständigen Klon mehr, sondern kannst einfach das bestehende Repo via git pull updaten.

vielen Dank. Für beide Tips. Das scheint es dann wohl zu sein. Von daher werd ich mich in Submodules einlesen und schauen, dass ich das Repo verschoben bekomme.

Vielen Dank.

sven