Ответы:
Основным недостатком является дисковое пространство. Сам репозиторий займет столько же места, сколько и набор «извлеченных» файлов. Это означает, что когда вы клонируете репозиторий, ваша коллекция будет занимать в два раза больше места на диске.
Хуже того, даже если вы удалите файлы, которые вам больше не нужны, в вашем хранилище останутся копии, которые займут место.
Возможно, вы захотите взглянуть на инструменты синхронизации, такие как 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 между компьютерами, например:
(из этой статьи )
Системы контроля версий в целом предназначены для обработки текстовых файлов. Каждый раз, когда вы обновляете двоичный файл, ему нужно создать совершенно новый файл, а не просто хранить дельту.
Как это может быть использовано в реальных условиях, так это то, что ваша библиотека будет использовать много места на диске, если вы будете регулярно ее менять.
Если вы говорите только о самом файле библиотеки, это может быть хорошо.
Еще одна проблема с этой настройкой заключается в том, что iTunes хранит свою базу данных в качестве проприетарного двоичного файла, который git не сможет выполнить слияние (нет, изменения в файле iTunes Music Library.xml не будут считываться iTunes) , Таким образом, если вы внесли изменения в метаданные или добавили дополнительные дорожки на обеих машинах, не было бы никакой возможности согласовать изменения, сделанные с обоих концов, в результате вы перезаписали бы одну версию базы данных другой и потеряли бы данные в процессе. ,
Проблемы с дисковым пространством, описанные выше, безусловно, имеют место. Но есть две отдельные проблемы. Одним из них является то, что вы должны хранить хранилище и данные, поэтому каждый файл сохраняется 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/