Контроль версий для MP3?

Question

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

Система контроля версий, в отличие от rsync/robocopy lashup, в грубом смысле этого слова кажется подходящей. Во-первых, задействовано несколько ОС (Windows, Mac, Linux). Во-вторых, было бы неплохо, если бы при обновлении тегов ID3 и тому подобного система могла просто обновить дельту файла, а не заново копировать весь файл. (Наконец, возможность обновления библиотеки через Интернет, а не по локальной сети, была бы очень полезна.)

Но у вашей классической системы CVS/SVN есть очевидный недостаток - необходим полный репозиторий для работы, и я бы предпочел не иметь двух копий моей папки 60gb+ MP3, где-нибудь на машине, а также не иметь дело с бинарными дельтами. Что ж.

Итак, Distributed Version Control начинает звучать довольно хорошо на этом этапе. Mercurial, git и bazaar хорошо смотрятся на бумаге, но у меня нет опыта работы с ними. Кто-нибудь пытался настроить DVCS "только для двоичных файлов" с любым из них? Любые рекомендации? Ловушки?

Answer 1

Это не совсем ответ на ваш вопрос, но я начал использовать DropBox для той же цели. Он кроссплатформенный, и вы можете получить 100 ГБ аккаунт, если не возражаете заплатить немного больше. Он также хранит ревизии в файлах, очень похожие на систему контроля версий.

Answer 2

Но у вашей классической системы CVS/SVN есть очевидный недостаток - необходим полный репозиторий для работы, и я бы предпочел не иметь двух копий моей папки 60gb+ MP3, где-нибудь на машине, а также не иметь дело с бинарными дельтами. Что ж.

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

Очень грубо: предположим, что наша система контроля версий не может эффективно хранить различия в двоичных файлах (не совсем так, но для простоты). Ваша коллекция - это 60 ГБ MP3-файлов. Если у вас есть в среднем 10 ревизий на файл, и мы пренебрегаем сжатием (потому что MP3 сжимают плохо), ваш репо будет около. 600 ГБ и ваша рабочая копия ок. 120 Гб.

Итак, Distributed Version Control начинает звучать довольно хорошо на этом этапе.

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

Те же предположения, что и выше, каждая копия будет иметь ок. 600 ГБ.

Суть в том, что распределенной системе потребуется больше места, чем централизованной.

РЕДАКТИРОВАТЬ:

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

Answer 3

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

Лично для моих больших двоичных мультимедийных коллекций меня не волнует возможность отмены изменений в любом файле. Все, что меня волнует, - это то, что коллекция синхронизируется между моими системами. Существует множество решений для синхронизации файлов, но у каждого из них есть свои плюсы и минусы. Некоторые утверждают, что они кроссплатформенные, но это означает только Win/Mac. Другие действительно кроссплатформенные, но не имеют достаточно больших ограничений размера / количества файлов, чтобы быть полезными для больших коллекций. Некоторые предлагают веб-доступ к файлам, но также страдают от ограничений размера / количества файлов. Любое решение, которое хранит копию ваших файлов на стороннем сервере, неизбежно будет стоить вам денег, если у вас большая коллекция файлов.

Answer 4

Не совсем ответ, но я думал, что поделюсь. Я начал использовать SVN для своих HD-видео проектов (например, для мероприятий и свадеб, где результатом является сильно отредактированное видео). Это начинает становиться действительно удивительным по нескольким причинам.

Обычно в видеопроекте содержится несколько, а может быть, десятки или даже сотни ГБ необработанных файлов AVCHD (по большей части всего несколько сотен МБ каждый с момента перехода с DV-лент;). Они добавляются и фиксируются один раз, а затем никогда не изменяются, поскольку затем выполняется вся работа над файлами проекта программного обеспечения для редактирования видео (очень маленькими и часто основанными на тексте или в формате xml), некоторыми неподвижными изображениями (которые иногда, но не очень часто изменяются) и различными другие файлы дескрипторов.

Маркировка и наименование клипов также хранятся в файлах проекта и не добавляются в реальные необработанные видеофайлы, что делает этот идеал идеальным. Скажем, база данных репозитория проекта начинается с 10 ГБ, обычно она заканчивается на 11 ГБ и состоит из ~ 100 ревизий. Конечный результат в разных форматах, конечно же, вообще не сохраняется в репозитории, так как его всегда можно сгенерировать заново.

Поскольку mp3-файлы, в частности, сохраняют свои метаданные в реальном mp3-файле, это представляет собой гораздо большую проблему, но в соответствии с этим вопрос о стековом потоке Subversion может решить эту проблему в конце, так как данные тега id3 хранятся в начале (или v1 в конце) файла. Тем не менее, поскольку v2.x может быть любой длины - я понятия не имею, что произойдет, если вы добавите дополнительные данные тега - если файл увеличится и, возможно, испортит дельта-сравнение, которое стоит протестировать ...

А хранилище дешево - всего 60 Гб? Получить несколько 1 ТБ дисков для хранилища и покончим с этим;)

Answer 5

Windows Vista & 7 предлагает теневое копирование / предыдущие версии. Он определенно не так богат, как настоящий поставщик систем управления версиями, но дает вам некоторые преимущества. Как уже говорили другие, хранилище, необходимое для размещения нескольких ревизий, вероятно, будет довольно большим - в зависимости от размера файлов.

Бесплатные и популярные SCM все так себе в задаче. SVN, например, будет работать нормально, но хранилище будет быстро расти, и локальная папка .svn также будет довольно большой.

Когда все сказано и сделано, вы можете захотеть просто скопировать всю партию файлов в безопасное место, прежде чем вносить какие-либо значительные изменения в свою коллекцию; когда вы на самом деле используете MP3 обычным образом, нет особой причины для изменения файлов, и затраты на ревизионную систему для просмотра редко изменяемых больших двоичных файлов, кажется, трудно оправдать ... но если вы ' установите его, тогда SVN, по крайней мере, делает двоичные различия, CVS делает полные копии (намного больше)