Відповіді:
Основним недоліком є дисковий простір. Сам сховище займе стільки ж місця, скільки і набір файлів "перевірених". Це означає, що коли ви клонуєте сховище, ваша колекція займає в основному вдвічі більше місця на диску.
Що ще гірше, навіть якщо ви видалите файли, які ви більше не хочете, у вашому сховищі все одно будуть копії, займаючи місця.
Можливо, ви захочете подивитися на такі засоби синхронізації, як унісон, який призначений для двосторонньої синхронізації файлів на декількох машинах.
Чи можете ви придумати будь-які причини, чому це було б поганою ідеєю?
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/