Контроль версий для больших двоичных файлов и> 1 ТБ хранилищ?

Question

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

Я ищу хорошую систему контроля версий, которая может выполнять только два простых требования:

1. хранить большие двоичные файлы (> 1 ГБ)
2. поддерживает репозиторий объемом> 1 ТБ (да, это ТБ)

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

Пока у меня есть некоторый опыт работы с SVN и CVS, однако я не совсем доволен производительностью обоих файлов с большими двоичными файлами (несколько файлов MSI или CAB будут иметь размер> 1 ГБ). Кроме того, я не уверен, хорошо ли они масштабируются с объемом данных, который мы ожидаем в ближайшие 2-5 лет (как я уже сказал, по оценкам> 1 ТБ)

Итак, у вас есть рекомендации? В настоящее время я также изучаю внешние возможности SVN и подмодули Git, хотя это будет означать несколько отдельных репозиториев для каждого программного пакета, и я не уверен, что это то, что нам нужно ..

Answer 1

Взгляните на Кабан , «Простое управление версиями и резервное копирование фотографий, видео и других двоичных файлов». Он может легко обрабатывать огромные файлы и огромные репозитории.

Answer 2

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

То, о чем вы на самом деле говорите, - это процесс, известный как управление конфигурацией.Если у вас есть тысячи уникальных программных пакетов, у вашего бизнеса должен быть менеджер конфигурации (человек, а не программное обеспечение ;-)), который управляет всеми конфигурациями (то есть сборками) для разработки, тестирования, выпуска, выпуска для каждого клиента и т. Д..

Answer 3

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

(Отказ от ответственности: я работаю в Perforce)

Answer 4

Обновление май 2017:

Git с добавлением GVFS (виртуальной файловой системы Git) может поддерживать практически любое количество файлов любого размера (начиная с самого репозитория Windows).: " Самое большое Git-репо на планете " (3,5 МБ, 320 ГБ).
Это еще не> 1 ТБ, но оно может масштабироваться там.

Работа сделана сGVFS медленно предлагается для апстрима (то есть для самого Git), но это все еще в стадии разработки.
GVFS внедряется в Windows, но вскоре будет реализована для Mac (потому что команда разработчиков Windows для Office требует этого) и Linux.

---

Апрель 2015

Git можно рассматривать как жизнеспособную VCS для больших данных с Git Large File Storage (LFS) (от GitHub, апрель 2015 г.).

git-lfs (см. git-lfs.github.com ) можно протестировать на сервере, который его поддерживает: lfs-test-server (или непосредственно на самом github.com):
Вы можете хранить метаданные только в git-репо, а большой файл - в другом месте.

Answer 5

• хранить большие двоичные файлы (> 1 ГБ)
• поддержка репозитория> 1 ТБ (да, это ТБ)

Да, это один из случаев, когда Apache Subversion должен полностью поддерживать.

Пока у меня есть некоторый опыт работы с SVN и CVS, но я не вполне устраивает производительность как с большими двоичными файлами (несколько файлов MSI или CAB будут> 1 ГБ). Кроме того, я не уверен, что они хорошо масштабируется с количеством данных, которые мы ожидаем в следующие 2-5 лет (как я уже сказал, по оценкам> 1 ТБ)

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

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

svn:externals не имеет ничего общего с поддержкой больших двоичных файлов или мультитерабайтных проектов. Subversion отлично масштабируется и поддерживает очень большие базы данных и кода в одном репозитории. Но Git делает не . С Git вам придется делить и разбивать проекты на несколько небольших репозиториев . Это приведет к множеству недостатков и постоянному PITA. Вот почему в Git есть много дополнений, таких как git-lfs, которые пытаются сделать проблему менее болезненной.

Answer 6

Это старый вопрос, но один из возможных ответов: https://www.plasticscm.com/. Их VCS может обрабатывать очень большие файлы и очень большие репозитории. Они были моим выбором, когда мы выбирали пару лет назад, но руководство подтолкнуло нас в другом месте.

Answer 7

Есть несколько компаний, которые предлагают продукты для «Общего доступа к файлам».Они могут реплицировать большие файлы в разные места, но имеют распределенные механизмы блокировки, поэтому только один человек может работать с любой из копий.Когда человек регистрирует обновленную копию, она копируется на другие сайты.Основное использование - это файлы CAD / CAM и другие большие файлы.См. Peer Software (http://www.peersoftware.com/index.aspx) и GlobalSCAPE (http://www.globalscape.com/).

)

Answer 8

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

(В вопросе также упоминаются файлы .cab & .msi: как правило, CI по вашему выбору имеет какой-то метод архивирования сборок . Это то, что вы в конечном итоге преследуете?)

Answer 9

Когда вам действительно нужно использовать VCS, я бы использовал svn, поскольку svn не требует копировать весь репозиторий в рабочую копию.Но ему все равно нужно дублировать объем дискового пространства, поскольку у него есть чистая копия для каждого файла.

С этим объемом данных я бы искал систему управления документами или (низкий уровень) использовал бы чтение-только сетевой ресурс с заданным процессом ввода.

Answer 10

Льготы, которые поставляются с системой управления версиями (журнал изменений, легкий доступ к rss и т. Д.), Не существуют на простом файловом ресурсе.

Если вы заботитесь только о функциях метаданных управления версиями и на самом деле не заботитесь о старых данных, то приемлемым вариантом может быть решение, использующее VCS без сохранения данных в VCS.

git-annex - это первое, что пришло мне в голову, но со страницы , что git-annex не , похоже, есть и другие похожие, но не совсем такие же альтернативы .

Я не использовал git-annex, но из описания и пошагового руководства звучит так, как будто это может работать для вашей ситуации.