Ein gemeinsam genutztes Git-Repository scheint also mehr oder weniger perfekt zu sein, um Ordner mit großen Blobs synchron zu halten. Ich habe etwa 700 GB an Bildern und Videos, die ich auf meine Computer verteilen möchte, aber die Verwendung von Git ohne weitere Ergänzungen führt zu einem enormen Festplattenverbrauch, der nicht wirklich nötig ist.
Wenn ich nun mit --shared (oder -s) klonen kann, erhalte ich ein Git-Repository ohne lokalen Objektspeicher (wenn ich das richtig verstanden habe), was so ziemlich alles ist, was ich brauche. Die Dokumentation beginnt jedoch mit „Wenn sich das zu klonende Repository auf dem lokalen Computer befindet ...“. clone -s funktioniert genauso gut über SSH, aber ich frage mich, was passiert, wenn sich das zu klonende Repository auf dem lokalen Computer befindet ...nichtauf dem lokalen Rechner. Da die Dokumentation von -s mit diesem Satz beginnt, habe ich das Gefühl, dass dieser ganze Fall nicht abgedeckt ist. Gibt es irgendetwas, worauf ich achten muss, außer Commits auf der Remote-Seite zu löschen, was dazu führen könnte, dass bestimmte Objekte (die möglicherweise noch lokal verwendet werden) durch den Garbage Collector gelöscht werden? (was sowieso nicht passieren wird, da ich auf dem Server Bare-Repositories verwenden möchte)
Antwort1
Ich liebe Git, aber leider ist Git nicht das richtige Tool für diese Aufgabe.
Git wurde entwickelt, um den Änderungsverlauf für Repositories mit überwiegend Textinhalten sehr effizient zu speichern. Obwohl Git das Speichern von Binärdateien unterstützt, muss es diese dauerhaft im Verlauf speichern, damit Sie auf jede Revision auschecken können, was sehr viel Speicherplatz beansprucht.
Unter der Annahme, dass Ihre Binärdateien nicht komprimierbar sind (Bilder, Filme, Musik usw.), ist die Größe des Git-Objektspeichers ungefähr so groß wie die des Tree Checkouts. Mit anderen Worten: Bei 700 GB an Originaldateien .gitverbraucht der Objektspeicher (Verzeichnis) ungefähr so viel und dann noch mehr, wenn Sie mit dem Commiten beginnen – also dem Hinzufügen und Entfernen von Inhalten.
Sie können einen sogenannten flachen Klon verwenden, der nur die letzte Revision des Objekts im Objektspeicher behält, flache Repositorys können jedoch nur geklont, aber nicht committet werden. In diesem Fall muss das Master-Git-Repository normal (nicht flach) sein und wird immer noch groß sein, alle flachen Klone werden jedoch eine angemessene Größe haben.
Sie sind wahrscheinlich besser dran, wenn Sie ein einfacheres Synchronisierungsschema wie rsync verwenden. In diesem Fall verlieren Sie jedoch die Möglichkeit, den Verlauf zu überprüfen – es gibt kein kostenloses Mittagessen :(
Antwort2
Ich weiß, dass das nicht wirklich eine Antwort auf Ihre Frage ist, aber... würde ich nichtrsyncwäre es viel einfacher, zwei Ordner synchron zu halten?