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

Question

Существует ли распределенная система управления версиями (git, bazaar, mercurial, darcs и т. Д.), Которая может обрабатывать файлы, размер которых превышает объем доступной оперативной памяти?

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

Да, Пластик СКМ . Он распространяется и управляет огромными файлами в блоках по 4 Мб, поэтому он не ограничен тем, что загружает их целиком в любое время. Найдите учебник по DVCS здесь: http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

Answer 4

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

• https://github.com/bup/bup
• http://blogs.kde.org/node/4440

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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