Насколько хорошо Git LFS обрабатывает небольшие файлы?

Существует ли наилучшая практика для файлов типов, хранящихся в Git LFS? В частности, для минимального размера?

Например, музыкальный файл размером 10 МБ был бы явным подспорьем, но как насчет 25kb png? Стоит ли вставлять LFS или лучше просто позволить Git обрабатывать его?

Меня беспокоит ухудшение производительности при проверке слишком большого количества небольших файлов в репозитории LFS. Есть ли данные о том, как расширение LFS поддерживает кучу меньших двоичных файлов? Желательно ли хранить файлы только с определенным порогом?

Ответ 1

Я не ожидал, что будет указано точное пороговое значение.

LFS сохраняет объем данных, которые необходимо обменять для синхронизации с удаленным репозиторием. Однако сохранение сохраняется только при условии, что сам большой файл не изменяется. Фактически для измененного файла вам понадобится вторая роутер-ручка для обработки изменения объекта LFS.

Таким образом, вы можете включать файлы меньшего размера с LFS, если в вашем случае они не меняются (часто). Конкретный разрыв будет зависеть от скорости ввода-вывода сервера и в основном от задержек и пропускной способности между хранилищем и клиентом.

В вашем примере я все равно ожидаю улучшения в случае, если параметры pngs не будут меняться. Как только они будут меняться (почти) на каждую фиксацию, даже большие файлы могут не пригодиться в LFS.

Кроме того, дополнительная стоимость второго тура будет становиться все менее и менее важной, чем больше типичные файлы. Особенно, когда размер класса файлов (суффикс) будет меняться в широком диапазоне и/или частота изменения в классе файлов покрывает широкий спектр, может быть, нет четкого ответа на ваш вопрос.