Naprawianie repozytorium git spowolnionego z powodu dużych plików binarnych

Question

Mamy repozytorium git zawierające kod źródłowy i pliki binarne. Nagie repo osiągnęło teraz około 9 GB, a klonowanie trwa wieki. Większość czasu spędza się w "remote: Compressing objects". Po zatwierdzeniu nowej wersji jednego z większych plików binarnych pobieranie trwa długo, a także zajmuje się kompresją obiektów na serwerze.

Po lekturze git pull without remotely compressing objects podejrzewam, że kompresja plików binarnych jest również bolesna, ale nie jestem w 100% pewna, jak to naprawić.

Jakie są dokładne kroki, aby naprawić nagie transakcje repo na serwerze? Zgaduję:

• Dodaj wpisy jak '* .zip -delta' dla wszystkich rozszerzeń chcę do .git/info/atrybuty
• Uruchom 'git repack', ale jakie opcje? Czy -adF zapakuje wszystko i zostawi mnie z repozytorium, w którym kompresja delta nie została kiedykolwiek wykonana dla określonych typów plików?
• Uruchom "git prune". Pomyślałem, że zrobiono to automatycznie, ale uruchomienie go, gdy grałem z gołym klonem repo, zmniejszyło rozmiar o ~ 2 GB.
• Klonowanie repozytorium, dodawanie i zatwierdzanie .gitattributes z tymi samymi wpisami, które dodałem w .git/info/atrybuty na gołym repo

Mam coś?

Aktualizacja:

Ciekawe wyniki badań na ten temat. Dzisiaj rozpocząłem nagły klon problematycznego repozytorium. Nasz nie tak potężny serwer z 4-bitowym ramkiem zabrakło pamięci i zaczął się wymieniać. Po 3 godzinach poddaję się ...

Potem sklonowałem nagi repozytorium z mojej aktualnej kopii roboczej. Klonowanie tego między stacjami zajęło ~ 5 minut. Następnie przekazałem go na serwer jako nowe repozytorium. Klonowanie repozytorium trwało tylko 7 minut.

Jeśli poprawnie zinterpretuję to, lepiej zapakowane repo działa o wiele lepiej, nawet bez wyłączania kompresji delta dla plików binarnych. Myślę, że oznacza to, że powyższe kroki są rzeczywiście tym, co chcę zrobić w krótkim czasie, ale dodatkowo muszę się dowiedzieć, jak ograniczyć ilość pamięci git, którą można użyć do pakowania/kompresji na serwerze, aby uniknąć zamiana.

Jeśli jest to ważne: serwer uruchamia git 1.7.0.4, a stacje robocze działają 1.7.9.5.

Aktualizacja 2:

zrobiłem następujące kroki na moim testrepo i myślę, że będzie okazja, aby zrobić je na serwerze (po kopii zapasowej)

• wykorzystanie pamięci Limit przy pakowaniu obiektów

  git config pack.windowMemory 100m
  git config pakiet.packSizeLimit 200m

• wyłączyć kompresję delta dla niektórych rozszerzeń

  echo '* .tar.gz -delta' >> Info/atrybuty
  echo '* .tar.bz2 -delta' >> info/atrybuty
  echo '* .bin -delta' >> info/atrybuty
  echo '* .png -delta' >> info/atrybuty

• Repack repozytorium zbierania śmieci

  git repack -a-D-F --window pamięć 100 --max sztuk wielkości 200
  git GC

Aktualizacja 3:

Niektóre nieoczekiwane efekty uboczne po tej operacji: Issues after trying to repack a git repo for improved performance

Answer 1

Powinieneś użyć innego mechanizmu do przechowywania dużych plików binarnych, jeśli są one generowane z czegoś, co nie może ich przechowywać, tylko kod, który je generuje, w przeciwnym razie sugeruję przeniesienie ich wszystkich do jednego katalogu i zarządzanie nim za pomocą rsync lub svn w zależności od Twoich potrzeb.

Answer 2

Podczas gdy twoje pytania pytają o to, jak sprawić, by twoje bieżące repozytorium było wydajniejsze, nie sądzę, żeby było to wykonalne.

stosować się do zaleceń w tłumie:

1. Najedź duże pliki binarne z Twojego repo
2. Najedź środowiska dev na maszynę wirtualną obrazu: https://www.virtualbox.org/
3. użyć tego skryptu Python do czyszczenia repo tych dużych binarnych bloków (użyłem tego na moim repo i działało świetnie) https://gist.github.com/1433794