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

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

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

Если Вы только говорите о самом файле библиотеки, это могло бы быть в порядке.

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

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

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

Сжатые данные (MP3s, JPEGs и т.д.) не могут быть сжаты мерзавцем далее, и так как эффективно необходимо сохранить две копии данных, это удвоит требуемое дисковое пространство (один для файлов, один для репозитория)

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

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

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

Так как Вы рассматриваете использование мерзавца, я предполагаю, что Вы достаточно довольны инструментами командной строки, таким образом, я предложил бы изучить использование rsync для синхронизации библиотеки iTunes между машинами. Самой большой проблемой, как joshhunt упомянутый, являются полные пути использования 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,99)

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

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

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

Вы могли бы думать о чем-то больше вроде rsync.

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

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

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