Лучшая практика хранения файлов .jar в VCS (SVN, Git,...)

Я знаю, что во времена Maven не рекомендуется хранить библиотеки в VCS, но иногда это имеет смысл.

Мой вопрос в том, как лучше хранить их - сжатые или несжатые? Несжатые они больше, но если их заменить пару раз более новыми, то, возможно, сохраненная разница между двумя несжатыми файлами .jar может быть намного меньше разницы сжатых. Кто-то сделал некоторые тесты?

Ответ 1

Лучшая практика для хранения файлов .jar в VCS (SVN, Git,...): do not.

Это может иметь смысл в CVCS (централизованный VCS), такой как SVN, который может обрабатывать миллионы файлов независимо от их размера.

Это не в DVCS, особенно в стиле Git (и его пределы):

Двоичные файлы не соответствуют требованиям VCS.
По умолчанию клонирование репо DVCS даст вам всю историю, со всеми версиями jar.
Это будет медленным и займет много дискового пространства, неважно, насколько хорошо сжаты эти банки.
Вы можете попытаться сыграть с мелким клонированием, но это очень непрактично.

Используйте второй репозиторий, например Nexus, для хранения этих банок и только ссылку a txt (или файл pom.xml для Maven), чтобы получить правильную банку версии.
Репозиторий артефакта более адаптирован для целей управления распространением и выпуском.

Все, что сказано, если вы должны хранить jar в репозитории Git, я бы сначала рекомендовал хранить их в сжатом формате (который является стандартным форматом для jar: см. Создание файла JAR)
Как сжатый, так и несжатый формат будут обрабатываться как двоичные с помощью Git, но, по крайней мере, в сжатом формате клонирование и проверка займет меньше времени.

Однако многие потоки упоминают возможность хранить банку в несжатом формате:

Я использую некоторые репозитории, которые вносят в них обычные картотеки размером 50 МБ.
Я убедил их не сжимать tarballs, а Git делает довольно приличную работу по дельта-сжатию между ними (хотя для этого требуется довольно много ОЗУ).

У вас есть еще дефинированный объект на Git здесь:

Это не имеет значения, если вы имеете дело с двоичным или текстовым текстом;

Дельта не обязательно относится к одному и тому же пути в предыдущей редакции, поэтому даже новый файл, добавленный в историю, может храниться в изолированной форме;

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

Итак, если клоны и проверки не являются обычными операциями, которые вы должны выполнять каждые 5 минут, сохранение jar в несжатом формате в Git имеет смысл, потому что:

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

Рекомендация: несжатый.

Ответ 2

Вы можете использовать аналогичное решение, найденное в ответах на "Uncompress OpenOffice files for better storage in version control" здесь, на SO, а именно используя clean/smudge gitattribute с помощью rezip в качестве фильтра для хранения файлов *.jar несжатых.

Ответ 3

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