Фиксирование репо git, которое замедляется из-за больших двоичных файлов

У нас есть репозиторий git, содержащий как исходный код, так и двоичные файлы. Голый репо теперь достиг ~ 9 ГБ, и клонирование требует много времени. Большую часть времени тратится на "remote: Compressing objects". После коммита с новой версией одного из более крупных двоичных файлов выборка занимает много времени, а также сжигает объекты на сервере.

После прочтения git pull без отдаленного сжатия объектов Я подозреваю, что дельта-сжатие двоичных файлов тоже вредит нам, но я не уверен на 100%, как чтобы исправить это.

Каковы конкретные шаги по исправлению голого репо на сервере? Мое предположение:

  • Добавьте записи типа '*.zip -delta' для всех расширений, которые я хочу в .git/info/attributes.
  • Запустить 'git repack', но с какими параметрами? Будет ли -adF перепаковать все, и оставить меня с репо, где дельта-компрессия никогда не выполнялась по указанным типам файлов?
  • Запустить 'git чернослив. Я думал, что это было сделано автоматически, но запустил его, когда я играл с голой клоню указанного репо, уменьшил размер на ~ 2 ГБ.
  • Клонирование репо, добавление и фиксация .gitattributes с теми же записями, что и я добавил в .git/info/attributes на голом репо

Я что-то на что-то?

Update:

Некоторые интересные результаты теста. Сегодня я начал голой клон проблемного репо. Наш не очень мощный сервер с 4 ГБ RAM исчерпал память и начал заменять. Через 3 часа я сдался...

Затем я вместо этого клонировал голый репо из моей современной рабочей копии. Клонирование того, что между рабочими станциями заняло ~ 5 минут. Затем я подтолкнул его к серверу как новое репо. Клонирование этого репо заняло всего 7 минут.

Если я правильно интерпретирую это, лучшее упакованное репо работает намного лучше, даже не отключая дельта-сжатие для двоичных файлов. Я предполагаю, что это означает, что приведенные выше шаги действительно являются тем, что я хочу сделать в краткосрочной перспективе, но, кроме того, мне нужно выяснить, как ограничить объем памяти git, который разрешен для упаковки/сжатия на сервере, поэтому я может избежать обмена.

В случае, если это имеет значение: сервер работает git 1.7.0.4, а рабочие станции работают 1.7.9.5.

Обновление 2:

Я сделал следующие шаги в своем тестовом режиме и подумал, что я смогу сделать их на сервере (после резервного копирования)

  • Ограничить использование памяти при упаковке объектов

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

  • Отключить дельта-сжатие для некоторых расширений

    echo '*.tar.gz -delta' → информация/атрибуты
    echo '*.tar.bz2 -delta' → информация/атрибуты
    echo '*.bin -delta' → информация/атрибуты
    echo '*.png -delta' → info/attributes

  • Хранить репозиторий и собирать мусор

    git repack -a -d -F --window-memory 100m - max-pack-size 200m
    git gc

Обновление 3:

Некоторые неожиданные побочные эффекты после этой операции: Проблемы после попытки переупаковать репозиторий git для повышения производительности

Ответы

Ответ 1

Пока ваши вопросы задают вопрос о том, как сделать ваш текущий репо более эффективным, я не думаю, что это возможно.

Следуйте советам толпы:

  • Извлеките свои большие двоичные файлы из своего репо.
  • Перенесите среду вашего разработчика на образ виртуальной машины: https://www.virtualbox.org/
  • Используйте этот Python script для очистки вашего репо этих больших двоичных блоков (я использовал его для своего репо, и он отлично работал) https://gist.github.com/1433794

Ответ 2

Вы должны использовать другой механизм для хранения больших двоичных файлов, если они сгенерированы из того, что вы могли бы просто не хранить, а только код, который их генерирует, в противном случае я предлагаю переместить все их в один каталог и управлять им с помощью rsync или svn в зависимости от ваших потребностей.