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

Question

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

Answer 3

ДА, Пластиковый SCM.Он распространяется и управляет огромными файлами блоками по 4 МБ, поэтому он не ограничен необходимостью загружать их полностью в mem в любое время.Руководство по 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, но:

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