Использование Git для управления библиотекой iTunes?

Question

Я подумывал об использовании Git для управления моей медиатекой iTunes и возможности синхронизации между компьютерами.

Можете ли вы вспомнить какие-либо причины, почему это было бы плохой идеей?

Answer 1

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

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

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

Answer 2

Можете ли вы вспомнить какие-либо причины, почему это было бы плохой идеей?

Git не подходит для такого использования.

Git работает так, как будто он хранит данные репозитория в папке .git/ . С текстом это не проблема, его можно легко сжать, а файлы небольшие - репозиторий может составлять один или два мегабайта.

Сжатые данные (MP3, JPEG и т.д.) Не могут быть сжаты при помощи git, и, поскольку вам фактически нужно хранить две копии данных, это удвоит требуемое дисковое пространство (одно для файлов, одно для хранилища)

Текст является крошечным и сжимаемым, и, что важно, вы можете легко "различать" между двумя ревизиями - только сохраняя изменения. Если вы изменяете только одну строку, git сохраняет только эту строку (и любые связанные метаданные, такие как сообщение коммита)

Бинарные файлы трудно различить, поэтому вы можете изменить теги на 100 файлах (например, чтобы добавить иллюстрации или изменить жанр), git сохранит новую копию этих файлов в своем каталоге .git/ . Скажем, вы удалите все комментарии из метаданных вашей музыки, тогда git сохранит еще одну полную копию ваших файлов! Это будет означать, что ваш репозиторий теперь будет в два раза больше ваших реальных файлов (скажем, у вас было 10 ГБ музыки, ваша папка с музыкой теперь будет более 30 ГБ)

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

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

<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>

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

Вы можете написать два сценария, один из которых обновляет пути от machineA к machineB и наоборот. Вы можете переместить свою медиатеку iTunes куда-нибудь вроде /User/Shared/Music/ чтобы пути были одинаковыми (хотя это может не работать для OS X -> Windows)

Существует несколько утилит для синхронизации библиотек iTunes между компьютерами, например:

• myTuneSync (19,95 долларов США)
• Синкопа (24,95 долларов США)
• SlingShot ($ 29.99USD)

(из этой статьи)

Answer 3

Я не уверен, есть ли у Git проблемы с размерами файлов в музыкальной библиотеке (он плохо работает с большими файлами, но я не уверен точно, насколько большой), но Джои Хесс написал программу под названием git annex для иметь дело с этим видом использования.

Answer 4

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

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

Если вы говорите только о самом файле библиотеки, это может быть хорошо.

Answer 5

Еще одна проблема, связанная с этой настройкой, заключается в том, что iTunes сохраняет свою базу данных в качестве проприетарного двоичного файла, который Git не сможет выполнить слияние (нет, изменения в файле iTunes Music Library.xml не будут считываться iTunes), Таким образом, если вы внесли изменения в метаданные или добавили дополнительные дорожки на обеих машинах, не было бы никакого способа согласовать изменения, сделанные с обоих концов, в итоге вы перезаписали бы одну версию базы данных другой и потеряли бы данные в процессе. ,

Answer 6

Возможно, вы думаете о чем-то более похожем на rsync .

Answer 7

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

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

Вот журнал, который иллюстрирует проблему. Обратите внимание, что Subversion на самом деле хранит три копии: одну в хранилище, одну в каталогах .svn в рабочей копии и саму рабочую копию. Тем не менее, он не использует никакого дополнительного пространства, поскольку я изменяю метаданные.

mat@Winter:~/temp$ git init repo
Initialized empty Git repository in /home/mat/temp/repo/.git/
mat@Winter:~/temp$ cp -r light_and_magic/ repo/
mat@Winter:~/temp$ cd repo/
mat@Winter:~/temp/repo$ du -hs .
101M    .
mat@Winter:~/temp/repo$ git add light_and_magic/
mat@Winter:~/temp/repo$ git commit -m 'First commit'
...
mat@Winter:~/temp/repo$ du -hs .
191M    .
mat@Winter:~/temp/repo$ id3v2 -a 'ladytron' light_and_magic/*.mp3
mat@Winter:~/temp/repo$ git commit -a -m 'changed metadata'
...
 15 files changed, 0 insertions(+), 0 deletions(-)
mat@Winter:~/temp/repo$ du -hs .
282M    .
mat@Winter:~/temp$ svnadmin create repo
mat@Winter:~/temp$ svn co file:///home/mat/temp/repo working
Checked out revision 0.
mat@Winter:~/temp$ cp -r light_and_magic/ working/
mat@Winter:~/temp$ svn add working/light_and_magic/
...
mat@Winter:~/temp$ svn commit -m 'First commit' working/
...
mat@Winter:~/temp$ du -hs repo
91M     repo
mat@Winter:~/temp$ du -hs working/
201M    working/
mat@Winter:~/temp$ id3v2 -a 'ladytron' working/light_and_magic/*.mp3        
mat@Winter:~/temp$ svn commit -m 'changed metadata' working/                      
...
mat@Winter:~/temp$ du -hs repo/
91M     repo/
mat@Winter:~/temp$ du -hs working/
201M    working/

Answer 8

Если я правильно помню, библиотеки iTunes хранят места для музыки в виде абсолютных путей, а не относительно файла библиотеки. Это может вызвать проблемы, если музыка хранится в двух разных местах на компьютерах.