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

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

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

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

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

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

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

20
git packaging svn version-control

10 ответов

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

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

5

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

8

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

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

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

апреля 2015 года

Git можно фактически рассматривать как жизнеспособный VCS для больших данных, с Git большое хранилище файлов (LFS) (по GitHub, апрель 2015).

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

https://cloud.githubusercontent.com/assets/1319791/7051226/c4570828-ddf4-11e4-87eb-8fc165e5ece4.gif

2

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

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

1

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

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

1

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

1

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

1

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

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

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

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

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

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

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

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

1

льготы, которые поставляются с системой управления версиями (changelog, easy RSS access etc.) не существуют в простом файле.

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

git-annex это первое, что пришло мне на ум, но из что git-приложение не

0