Стоит ли использовать Git для управления многими файлами размером более 500 МБ - PullRequest
10 голосов
/ 19 ноября 2009

Я бы поставил под контроль версий большой объем данных, то есть структуру каталогов (с глубиной <= 5) с сотнями файлов размером около 500 МБ). </p>

Мне нужна система, которая мне помогает: - чтобы определить, были ли файлы изменены - определить, были ли файлы добавлены / удалены - клонировать весь репозиторий в другом месте - сохранить «контрольную точку» и восстановить ее позже

Мне не нужен sha1 для обнаружения изменений, что-то более быстрое приемлемо.

Стоит ли мерзавец за это? Есть лучшая альтернатива?

Ответы [ 5 ]

10 голосов
/ 19 ноября 2009

Как я упоминал в " Каковы ограничения Git ", Git не предназначен для управления большими файлами (или большими двоичными файлами в этом отношении).

Git понадобится, если вам нужно:

  • знать, что на самом деле изменилось в файле. Но для уровня каталогов другие ответы лучше (Unison или rsynch)
  • сохраняйте тесную близость (то есть "одну и ту же ссылку") между вашими данными разработки и этими большими ресурсами. Помочь будет только одна ссылка, но тогда вам понадобится форк Git, например git-bigfiles , чтобы эффективно управлять ими.

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

К сожалению, rsync тоже не совсем подходит для наших целей.

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

Хорошо, а как насчет другой идеи: давайте разделим файл на куски и проверим каждый из этих блоков на git отдельно .
Тогда дельта-сжатие Git не будет слишком много, чтобы пережевать за раз, и нам нужно только отправить измененные блоки ...

На основе gzip --rsyncable, с POC, доступным в этом репозитории Git .

8 голосов
/ 18 ноября 2010

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

http://git -annex.branchable.com

1 голос
/ 20 ноября 2009

Если вы работаете в системе Unix (вероятно, так как вы используете git):

  • Используйте git-репо для всего мелкого.
  • Symlink больших файлов из одной папки "large_files" в соответствующие места в вашем хранилище.
  • Сделайте резервную копию папки large_files, используя более традиционную систему резервного копирования без поддержки версий, время от времени объединяйте их все в zip-файл, если вам нужно передать их другим.

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

1 голос
/ 19 ноября 2009

Синхронизатор файлов Unison - отличный инструмент для поддержки нескольких копий больших двоичных файлов. Он будет делать все, что вы просите, кроме сохранения контрольной точки - но вы можете сделать это с копией rsync hardlink.

0 голосов
/ 19 ноября 2009

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

...