Могут ли GIT, Mercurial, SVN или другие инструменты контроля версий работать хорошо, когда в дереве проекта есть двоичные файлы?

Question

Иногда в нашем дереве проекта могут быть двоичные файлы, такие как jpg, png, doc, xls или pdf. Могут ли GIT, Mercurial, SVN или другие инструменты работать хорошо, когда изменяется только часть двоичного файла?

Например, если спецификация написана в .doc и является частью репозитория, то если она имеет размер 4 МБ и отредактирована 100 раз, но только на 1 или 2 строки, и проверена 100 раз в течение года, тогда это 400 МБ.

Если это 100 разных файлов .doc и .xls, то это 40 ГБ ... это не тот размер, которым легко управлять.

Я попробовал GIT и Mercurial и вижу, что они оба, кажется, добавляют большой размер данных, даже когда 1 строка изменяется в .doc или .pdf. Есть ли другой способ внутри GIT или Mercurial или SVN, который может сделать эту работу?

Answer 1

В целом, системы контроля версий лучше работают с текстовыми файлами. Вся концепция слияния / конфликта действительно основана на исходном коде. Тем не менее, SVN работает довольно хорошо для двоичных файлов. (Мы используем его для версии чертежей САПР.)

Я укажу, что блокировка файла (svn: needs-lock) в значительной степени необходима, когда над общим двоичным файлом работает несколько человек. Без блокировки файлов 2 человека могут одновременно работать с двоичным файлом. Кто-то фиксирует свои изменения в первую очередь. Угадай, что происходит с человеком, который не совершал. Вся та бинарная / неумолимая работа, которую они проделали, фактически потеряна. File-lock сериализует работу над файлом. Вы теряете возможности «одновременного» доступа системы контроля версий, но у вас все еще есть преимущества журнала фиксации, отката к предыдущей версии и т. Д.

Клиент TortoieSVN достаточно умен, чтобы использовать встроенный в MS Word инструмент слияния для сравнения файла doc / docx. Он также имеет параметры конфигурации, позволяющие вам указать альтернативные инструменты сравнения, основанные на расширении файла, что довольно круто. (Жаль, что никто не сделал diff-инструмент для нашего пакета CAD).

DVCS текущего поколения, такие как Git или Hg, имеют тенденцию сосать двоичные файлы. У них нет какого-либо механизма блокировки файлов.

Answer 2

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

Если вы хотите зафиксировать такие документы, рассмотрите возможность фиксации несжатых вариантов - RTF вместо DOC, TeX вместо PDF и т. Д. Если система управления версиями использует сжатие для сжатия своего внутреннего хранилища, тогда этот метод должен работать довольно хорошо. Например, в Git ,

Вновь добавленные объекты сохраняются полностью с использованием сжатия zlib.

РЕДАКТИРОВАТЬ: Я просто хотел отметить, что даже RTF ужасен, но не так ужасен, как DOC. Если вы можете переключиться на TXT или TeX для ваших документов, это было бы лучше.

Answer 3

Я использовал git для синхронизации моих Документов между компьютерами Mac, Linux и Windows. Мне пришлось сделать один редизайн, чтобы обойти ограничение в 2Гб файла в Windows. В общей сложности это около 7 Гб в 3 репозиториях, которые регулярно синхронизируются. В определенный момент у меня даже была удаленная копия на хост-сервере в интернете.

Теперь мне почти никогда не нужно клонировать эти репозитории, поэтому большой размер не сильно мешает. Я также вижу, что .git не увеличивается значительно, и он остается на уровне 40-60% от размера извлеченных документов, PDF, Excel листов.

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

Однако, по сравнению с альтернативой отсутствия документов под контролем версий, я счастлив жить с менее чем звездными коэффициентами сжатия

Answer 4

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

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

Answer 5

ИМХО, вам следует прекратить использовать SCM для управления такими документами. Вы должны использовать специальные инструменты, такие как Alfresco (я уверен, что есть много других инструментов для управления документами).