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

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

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

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

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

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)

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

I'm not sure whether Git has problems with the sizes of files in a music library (it doesn't perform well with large files, but I'm not sure exactly how large), but Joey Hess wrote a program called git annex for dealing with this kind of use case.

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

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

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

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

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

Проблемы с дисковым пространством, описанные выше, безусловно, имеют место. Но есть две отдельные проблемы. Во-первых, вы должны хранить хранилище и данные, поэтому каждый файл сохраняется 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/ 

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