2016-03-04 4 views
17

Gibt es eine Best Practice für die in Git LFS gespeicherten Dateitypen? Speziell für die Mindestgröße?Wie gut verarbeitet Git LFS kleine Dateien?

Zum Beispiel wäre eine 10-Mb-Musikdatei offensichtlich, aber was ist mit einem 25kb Png? Lohnt es sich, in LFS zu investieren oder besser, Git einfach damit umgehen zu lassen?

Mein Anliegen ist Leistungseinbuße beim Überprüfen zu vieler kleiner Dateien in einem LFS Repo. Gibt es irgendwelche Daten darüber, wie die LFS-Erweiterung gegen eine Menge kleinerer Binärdateien steht? Ist es ratsam, Dateien nur über einen bestimmten Größengrenzwert zu speichern?

+2

+1 Ich möchte auch die Antwort darauf wissen, zum Beispiel UE4 hat viele binäre Uasset-Dateien. Viele sind klein (10-100 KB) und einige sind groß (50 MB +). Ich möchte nur "* .uasset" verfolgen, wenn git-lfs gut genug funktioniert. – Chad

Antwort

10

Ich würde nicht erwarten, dass ein genauer Schwellenwert angegeben wird.

LFS speichert die Datenmenge, die für die Synchronisation mit einem Remote-Repository ausgetauscht werden muss. Das Speichern gilt jedoch nur, solange sich die große Datei selbst nicht ändert. Für eine geänderte Datei benötigen Sie einen zweiten Rountrip, um die Änderung an einem LFS-Objekt zu verarbeiten.

Sie können also kleinere Dateien mit LFS einschließen, wenn sich diese in Ihrem Anwendungsfall nicht (häufig) ändern. Der spezifische Break Even hängt von der E/A-Geschwindigkeit des Servers und hauptsächlich von der Latenz und dem Durchsatz zwischen Repository und Client ab.

In Ihrem Beispiel würde ich immer noch Verbesserungen erwarten, falls sich die PNGs nicht ändern. Sobald sie sich (fast) bei jedem Commit ändern, können auch größere Dateien nicht von LFS profitieren.

Auch die zusätzlichen Kosten der zweiten Runde werden immer weniger wichtig, je größer die typischen Dateien werden. Insbesondere wenn die Größe einer Dateiklasse (Suffix) über einen weiten Bereich variiert und/oder die Änderungshäufigkeit innerhalb einer Dateiklasse ein breites Spektrum abdeckt, gibt es möglicherweise keine klare Antwort auf Ihre Frage.

+1

Ich hatte den Eindruck, dass der Vorteil von LFS darin lag, dass häufig wechselnde Binärdateien die Repo-Größe nicht aufblähen. Aber es hört sich so an, als würden Sie sagen, dass es nicht hilft, wenn sich Dateien häufig ändern; also warum es jemals benutzen? – Chad

+0

hätte genauer sein sollen. Die Repo-Größe im Sinne des Objekt-Blobs (Pack-Datei) ist kleiner. Ich bezog mich auf die Menge an Daten, die zwischen Client und Server (sozusagen auf Push und Pull) übertragen werden sollte. Da lokale Operationen in der Regel nicht von großer Bedeutung sind und Änderungen ohnehin Vergleiche erfordern, konzentrierte ich mich auf große Kostenaspekte bei großen Dateien. LFS speichert jede Operation, die die Objektdaten verarbeiten muss. – rpy

+0

Solange nur Index/Metadaten betroffen sind, sollten Sie keinen Unterschied feststellen. Mit LFS wird die Gesamtgröße aller Dateien, die Informationen speichern (vollständiges Repository), nicht kleiner (noch größer, um ehrlich zu sein, alle Versionen müssen noch gespeichert werden), aber das Speichern von Index-/Metadaten beschleunigt die Ermittlung der geänderten Objekte (lokal oder zwischen lokalen und remore Instanzen). So werden die späteren Operationen beschleunigt. Dies kommt vor allem dann zum Tragen, wenn das gespeicherte LFS-Objekt nicht geändert wurde. – rpy