Ich lese immer mal wieder, dass GIT-Repos nicht größer als 1 GiB sein sollten, aber weniger dazu warum genau, was also alles negatives mit zunehmender Größe passiert. Zumal es ja auch verschiedene Szenarien der zunehmenden Größe gibt: Einfach wahnsinnig viele einzelne Binarys, die für sich genommen gar nicht so groß sind, in Summe aber schon. Oder eben sehr wenige, davon aber extrem große Video-/Audiodateien etc.
Das sollte doch allein schon einen Unterschied machen, oder?
Viele kleinere Dateien dürften leichter zu handhaben sein, die Chance auf Deduplizierung vergrößern etc. G gleichzeitig ist es nicht soo ein Problem, wenn immer mal wieder 100 MiB in 10 Dateien gehasht werden müssen, vergleichen mit 10 Dateien die jeweils 1 GiB sind.
Beispiele für die unterschiedlichen Anwendungszwecke wären z.B. das im Artikel genannte Audio-/Video-Editing vs. binäre Deployments für Kunden über ein GIT-Repo. Ich kennen z.B. einen Fall, da hat ne Firma grundsätzlich alle Deployments an Kunde in einer einfachen Verzeichnisstruktur aufgehoben. Das alles in GIT wäre viel sinnvoller gewesen, weil nicht geänderte Dateien dann dedupliziert würden und man per Branches/Tags trotzdem an alles ran kommt, per Commit Message dokumentieren kann, warum es ein neues Release gibt usw. Gleichzeitig könnte man Kunden-spezifische Konfigurationen als Dienstleistung gleich mit versionieren oder das den Kunden selbst machen lassen.
Das funktioniert mit SVN und einzelnen mehrere MiB großen Binarys auch schon hervorragend und sollte es mit GIT auch. In solchen Fällen sehe ich nicht, warum man da mit GIT-Annex oder LFS anfangen sollte. Da wäre es noch eher einfacher, absolute Repo-Größen erst mal durch Aufteilung der Kunden in ihre einzelnen Repos zu entschärfen. Und so kann man das in anderen Fällen ja auch, ein Projekt ein Repo. Dafür muss man sich eben nicht mit zusätzlichem Speicher rumschlagen und macht sich nicht von anderen Projekten abhängig.