Есть ли распределенная VCS, которая может управлять большими файлами?

Есть ли система управления распределенной версией (git, базар, меркурий, darcs и т.д.), которая может обрабатывать файлы, большие, чем доступная оперативная память?

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

Я последний раз смотрел на это примерно год назад, и ни один из очевидных кандидатов не допустил этого, так как все они предназначены для разброса памяти в скорости. Это оставило меня с VCS для управления кодом и еще что-то ( "программное обеспечение управления активами" или просто rsync и скрипты) для больших файлов, что довольно уродливо, когда структуры каталогов этих двух перекрываются.

ОТВЕТЫ

Ответ 1

Прошло 3 года с тех пор, как я задал этот вопрос, но с версии 2.0 Mercurial включает расширение больших файлов, которое выполняет то, что я изначально искал:

Расширение больших файлов позволяет отслеживать большие несжимаемые двоичные файлы в Mercurial, не требуя чрезмерной полосы пропускания для клонов и выдержек. Файлы, добавленные как большие файлы, не отслеживаются напрямую Mercurial; скорее, их ревизии идентифицируются контрольной суммой, а Mercurial отслеживает эти контрольные суммы. Таким образом, когда вы клонируете репозиторий или втягиваете в набор изменений, большие файлы в старых версиях репозитория не нужны, и загружаются только те, которые необходимо обновить до текущей версии. Это экономит дисковое пространство и пропускную способность.

Ответ 2

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

Вы можете записать git: они заинтересованы в необработанной производительности для варианта использования ядра ядра Linux. Невероятно, что они когда-либо соглашатся на компромисс производительности при масштабировании до огромных двоичных файлов. Я не знаю о Mercurial, но они, похоже, сделали аналогичный выбор, как git, связав свою модель работы с моделью хранения для производительности.

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

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

Полное раскрытие: Я бывший сотрудник Canonical и тесно сотрудничал с разработчиками Bazaar.

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

Ответ 7

Я пришел к выводу, что лучшим решением в этом случае будет использование ZFS.

Да ZFS не является DVCS, но:

  • Вы можете выделить место для репозитория с помощью создания новой FS
  • Вы можете отслеживать изменения, создавая моментальные снимки.
  • Вы можете отправлять снимки (коммиты) в другой набор данных ZFS