Затраты на использование управления исходным кодом для синхронизации папок с тяжелыми носителями

Question

Я думал об использовании существующей удаленно подключенной инфраструктуры репозиториев SVN в качестве метода синхронизации папок мультимедиа.

Под медиа я имею в виду около 1 Тб видеоконтента.

Есть ли какой-либо недостаток при использовании SVN?

Эффективен ли протокол передачи для передачи больших файлов?

Есть ли накладные расходы в хранилище?

Спасибо

Answer 1

Как я уже сказал в своем комментарии, SVN - это контроль версий. Это не инструмент синхронизации, даже если вы можете использовать его для этой цели.

Тем не менее, SVN хорошо работает с двоичными файлами (например, с вашими медиа-файлами). Конечно, вы не можете получить diff для двоичных файлов, но это вполне нормально для хранилища.

Как указано в руководстве SVN:

Обратите внимание, что файл является двоичным или нет, не влияет на количество пространства хранилища, используемого для хранения изменений в этом файле, и при этом влияет на объем трафика между клиентом и сервером. Для хранения и в целях передачи, Subversion использует метод сравнения, который работает одинаково хорошо для двоичных и текстовых файлов; это совершенно не связано с метод сравнения, используемый командой 'svn diff'.

Но помните, что если вам нужна только синхронизация, у вас могут быть лучшие варианты, чем у SVN. Поэтому попробуйте взглянуть на другие решения, такие как, например, rsync , прежде чем использовать SVN.

Answer 2

Я настоятельно рекомендую вам не использовать Subversion (или любую систему контроля версий, разработанную для исходного кода) для этого. Subversion может обрабатывать двоичные файлы, но у вас нет возможностей слияния, сравнения и т. Д., Которые являются основной причиной использования чего-то вроде Subversion. Технически это скорее всего сработает; Тем не менее, есть гораздо лучшие инструменты для работы.

Если все, что вы делаете, это синхронизация папок, попробуйте что-то вроде rsync .

Что-то вроде AlienBrain может предоставить вам возможности управления версиями, если это необходимо.

Answer 3

Существуют значительные издержки на стороне клиента Subversion.

Основная проблема использования subversion для больших медиа-файлов заключается в том, что стандартный клиент хранит «нетронутые» копии ваших файлов в локальной рабочей области, таким образом эффективно удваивая размер извлеченной копии вашей библиотеки. Это осознанный выбор для конструкторов, который подходит для стандартного сценария управления исходным кодом Subversion, но не оптимален для больших двоичных файлов. Однажды были альтернативные клиенты, у которых нет этой проблемы - я не смотрел в последнее время.

На стороне сервера Subversion часто возникают издержки / неэффективность.

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

Допущения в инструментах SCM

Я не согласен с тем, что инструменты SCM обязательно являются плохим выбором для того, что вы пытаетесь сделать, но большинство из них не предназначены для этого и поэтому имеют проблемы. Для моих требований к мультимедиа рабочий процесс намного ближе к инструменту SCM, чем инструмент синхронизации, такой как rsync, unison или тому подобное. Однако некоторые фундаментальные предположения в SCM не подходят для больших файлов.

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

Заключение

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

Когда использовать Subversion

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

Если вы выдвигаете ограничения на объем хранилища (SSD?), Тогда подрывная работа «из коробки», вероятно, не то, что вам нужно, хотя вы все равно сможете использовать ее как часть своего решения.