Hier mal ein Fall für Extrem-Repos: Angenommen, im Repository tummeln sich mehrere Gigabyte Daten, beispielsweise weil man ganze Filmschnittprojekte dort ablegt (vermutlich ohnehin eine schlechte Idee), dann steht man vor zwei Problemen: Erstens dauert ein Clonen ewig, und zweitens ist irgendwann auch die größte Festplate voll. Git hat dafür eine einfache Lösung: Referenz-Repos.
Bevor ich weitermache, eine kurze Warnung: Referenz-Repos sind nicht ohne Risiko. Das ist möglicherweise nichts für Leute, die gerne an der History rumbasteln.
mkdir -p /mirror
git clone --bare git@server:/myrepo.git /mirror/myrepo.git
git clone --reference /mirror/myrepo.git git@server:/myrepo.git myrepo
Das erste Clonen erzeugt ein (lokales) Bare-Repo, das zweite verwendet das als Referenz. Den besten Effekt erzielt man, wenn beide Repos auf dem gleichen Filesystem liegen, und es lohnt sich natürlich nur, wenn man mehr als eine lokale Kopie braucht. Das Referenz-Repo muss jetzt wie ein public repo verwendet werden: Verschwinden von dort Commits, sind auch die darauf aufbauenden Repos kaputt. Also Vorsicht.
Findet man sich mit den Beschränkungen ab, bekommt man schnelle und kleine lokale Arbeitskopien. Das Referenz-Repo kann man leicht mit Cron-Jobs aktuell halten: je aktueller das Referenz-Repo, desto weniger Daten müssen die Arbeitskopien separat übers Netz schaufeln. Ich habe allerdings nicht ausprobiert, was passiert, wenn man die History im remote Repo umschreibt oder dort einen Commit löscht. Hausaufgabe: Ausprobieren, ob die Arbeitsrepos dabei beschädigt werden.
Das Ergebnis kann es aber durchaus wert sein: In meinem Falle ist ein 8GB Arbeitsrepo auf 3GB geschrumpft -- 5GB müssen beim Clonen also nicht mehr über die Leitung.
(Nein, es war kein Filmschnittprojekt.)
Keine Kommentare:
Kommentar veröffentlichen