Может МЕРЗАВЕЦ, Подвижный, SVN, или другие инструменты управления версиями работают хорошо, когда дерево проекта имеет двоичные файлы?

Иногда наше дерево проекта может иметь двоичные файлы, такие как jpg, png, документ, xls, или PDF. Может МЕРЗАВЕЦ, Подвижный, SVN, или другие инструменты делают хорошее задание, когда только часть двоичного файла изменяется?

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

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

Я судил МЕРЗАВЦА и Подвижный и вижу, что они оба, кажется, добавляют большой размер данных, даже когда 1 строка изменяется в .doc или .pdf. Есть ли другой путь в МЕРЗАВЦЕ или Подвижен или SVN, который может сделать задание?

9
задан nopole 6 June 2010 в 08:57
поделиться

5 ответов

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

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

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

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

13
ответ дан 4 December 2019 в 08:32
поделиться

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

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

3
ответ дан 4 December 2019 в 08:32
поделиться

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

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

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

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

3
ответ дан 4 December 2019 в 08:32
поделиться

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

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

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

EDIT: Я просто хотел отметить, что даже RTF ужасен, но не так ужасен, как DOC. Если вы можете перейти на TXT или TeX для своих документов, это было бы лучше.

5
ответ дан 4 December 2019 в 08:32
поделиться

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

1
ответ дан 4 December 2019 в 08:32
поделиться
Другие вопросы по тегам:

Похожие вопросы: