Затраты на использование управления исходным кодом для синхронизации папок с тяжелыми файлами
Я думал об использовании существующей удаленно подключенной инфраструктуры репозиториев SVN в качестве метода синхронизации папок мультимедиа.
Под медиа я имею в виду около 1 Тб видеоконтента.
Есть ли какой-либо недостаток, делая это с помощью SVN?
Эффективен ли протокол передачи для передачи больших файлов?
Есть ли накладные расходы в хранилище?
Спасибо
3 ответа
Как я уже сказал в своем комментарии, SVN - это система контроля версий. Это не инструмент синхронизации, даже если вы можете использовать его для этой цели.
Тем не менее, SVN хорошо работает с двоичными файлами (такими как ваши медиа-файлы). Конечно, вы не можете получить diff для двоичных файлов, но это вполне нормально для хранилища.
Как говорится в руководстве SVN:
Обратите внимание, что то, является ли файл двоичным или нет, не влияет на объем пространства хранилища, используемого для хранения изменений в этом файле, и не влияет на объем трафика между клиентом и сервером. В целях хранения и передачи Subversion использует метод сравнения, который одинаково хорошо работает с двоичными и текстовыми файлами; это совершенно не связано с методом сравнения, используемым командой 'svn diff'.
Но помните, что если вам нужна только синхронизация, у вас могут быть лучшие варианты, чем у SVN. Поэтому попробуйте взглянуть на другие решения, например, на rsync, прежде чем использовать SVN.
Я настоятельно рекомендую вам не использовать Subversion (или любую систему контроля версий, разработанную для исходного кода) для этого. Subversion может обрабатывать двоичные файлы, но у вас нет возможностей слияния, сравнения и т. Д., Которые являются основной причиной использования чего-то вроде Subversion. Технически это скорее всего сработает; Тем не менее, есть гораздо лучшие инструменты для работы.
Если все, что вы делаете - это синхронизируете папки, попробуйте что-то вроде rsync.
Что-то вроде AlienBrain может предоставить вам возможности управления версиями, если это необходимо.
Существенные накладные расходы на стороне клиента Subversion.
Основная проблема использования subversion для больших медиа-файлов заключается в том, что стандартный клиент хранит "нетронутые" копии ваших файлов в локальной рабочей области, таким образом эффективно удваивая размер извлеченной копии вашей библиотеки. Это осознанный выбор для конструкторов, который подходит для стандартного сценария управления исходным кодом Subversion, но не оптимален для больших двоичных файлов. Однажды были альтернативные клиенты, у которых нет этой проблемы - я не смотрел в последнее время.
На стороне сервера subversion часто возникают издержки / неэффективность.
Вторичная проблема заключается в том, что если вы храните сжатые двоичные файлы, небольшое изменение в содержимом файла приведет к совершенно другому результату сжатия, что сделает бесполезной стратегию хранения дельта-подрывных операций. Обратите внимание, что MP3 и многие видео форматы сжимаются, но это сжатие происходит на блоках. Таким образом, пока вы видите эту проблему в действии - небольшое изменение повлияет на весь блок - оно не обязательно повлияет на весь файл.
Допущения в инструментах SCM
Я не согласен с тем, что инструменты SCM обязательно являются плохим выбором для того, что вы пытаетесь сделать, но большинство из них не предназначены для этого и поэтому имеют проблемы. Для моих требований к мультимедиа рабочий процесс намного ближе к инструменту SCM, чем инструмент синхронизации, такой как rsync, unison или тому подобное. Однако некоторые фундаментальные предположения в SCM плохо работают с большими файлами.
Если у вас есть рабочий процесс, который создает много изменений в файлах, вы, вероятно, захотите довольно агрессивно очистить старую версию ваших данных. Большинство инструментов SCM разработаны с учетом того, что старые данные чрезвычайно важны, а также что хранилище старых данных относительно дешево (файлы небольшие и хорошо сжимаются). Поэтому, хотя все инструменты SCM моего знакомого (многие!) Имеют способы сделать это, это обычно (и намеренно) сделать нелегко.
Заключение
В заключение, у вас есть выбор неприятных вариантов. Инструменты SCM, такие как subversion, имеют допущения относительно пространства хранения и хранения, которые могут быстро свести на нет требования к хранилищу, но инструменты синхронизации файлов обычно не поддерживают рабочий процесс, который большинству людей действительно нравится в их медиатеке.
Когда использовать Subversion
Если вы не возражаете удвоить дисковое пространство, используемое на клиентских устройствах, и у вас есть сервер с дополнительным вдвое большим дисковым пространством (пространство для расширения), и вы ожидаете изменять свои файлы довольно редко (например, просто меняйте теги MP3 или что-то подобное) тогда Subversion может работать хорошо для вас.
Если вы раздвигаете ограничения на объем хранилища (SSD?), То подрывная деятельность "из коробки", вероятно, не то, что вам нужно, хотя вы все равно сможете использовать ее как часть своего решения.