Jawaban:
Kelemahan utama adalah ruang disk. Repositori itu sendiri akan mengambil jumlah ruang yang sama dengan set file "check-out". Ini berarti ketika Anda mengkloning repositori koleksi Anda pada dasarnya akan mengambil ruang disk dua kali lebih banyak.
Lebih buruk lagi, bahkan jika Anda menghapus file yang tidak lagi Anda inginkan, masih akan ada salinan di repositori Anda, yang menghabiskan ruang.
Anda mungkin ingin melihat alat sinkronisasi seperti serempak yang dirancang untuk sinkronisasi dua arah file di beberapa mesin.
Bisakah Anda memikirkan alasan mengapa ini merupakan ide yang buruk?
Git tidak cocok untuk penggunaan seperti itu.
Cara git bekerja adalah menyimpan data repositori di .git/folder. Dengan teks, ini bukan masalah, ia dapat dikompres dengan mudah, dan file-file tersebut kecil - repositori mungkin satu atau dua megabyte.
Data terkompresi (MP3, JPEG, dll.) Tidak dapat dikompres oleh git lebih lanjut, dan karena Anda secara efektif perlu menyimpan dua salinan data, ini akan menggandakan ruang disk yang diperlukan (satu untuk file, satu untuk repositori)
Teks kecil, dan dapat dikompresi, dan yang penting Anda dapat dengan mudah "membedakan" antara dua revisi - hanya menyimpan perubahan. Jika Anda hanya mengubah satu baris, git hanya menyimpan satu baris itu (dan metadata terkait apa pun, seperti pesan komit)
File biner sulit dibedakan, jadi katakanlah Anda memodifikasi tag pada 100 file (katakanlah, untuk menambahkan karya seni, atau mengubah genre), git akan menyimpan salinan baru dari file-file itu di .git/direktori itu. Katakanlah Anda kemudian menghapus semua komentar dari metadata musik Anda, git kemudian akan menyimpan salinan lengkap file Anda! Ini berarti repositori Anda sekarang akan lebih dari dua kali ukuran file Anda yang sebenarnya (katakanlah Anda memiliki 10GB musik, folder musik Anda sekarang akan lebih dari 30GB)
Seperti yang saya katakan, git tidak cocok untuk hal-hal seperti itu - itu ditujukan untuk melacak kode sumber, dengan banyak perubahan kecil pada file teks, bukan file biner besar. Tidak ada gunanya menyimpan riwayat revisi perpustakaan musik Anda, ketika semua yang Anda butuhkan alat sinkronisasi.
Karena Anda mempertimbangkan untuk menggunakan git, saya menganggap Anda cukup senang dengan alat-alat baris perintah, jadi saya akan menyarankan untuk menggunakan rsync untuk menyinkronkan perpustakaan iTunes Anda di antara mesin-mesin. Masalah terbesar, sebagaimana disebutkan joshhunt, adalah iTunes menggunakan jalur absolut ke file media, sehingga iTunes Library.xmlfile tersebut berisi hal-hal seperti ..
<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>
Jika Anda menggunakan OS yang sama, dan nama pengguna yang sama di semua mesin, ini bukan masalah - simpan file di jalur yang sama dan itu akan berfungsi dengan baik. Jika tidak, segalanya menjadi sedikit lebih rumit ..
Anda bisa menulis dua skrip, satu yang memperbarui jalur dari machineA ke machineB, dan sebaliknya. Anda dapat memindahkan iTunes Library Anda ke suatu tempat seperti /User/Shared/Music/sehingga jalurnya sama (walaupun ini mungkin tidak berfungsi untuk OS X -> Windows)
Ada beberapa utilitas untuk menyinkronkan iTunes Library di antara mesin, seperti ..
(dari artikel ini )
Sistem kontrol versi pada umumnya dirancang untuk menangani file teks. Setiap kali Anda memperbarui file biner, ia perlu membuat file yang sama sekali baru dan bukan hanya menyimpan delta.
Cara ini diterjemahkan ke penggunaan dunia nyata adalah bahwa perpustakaan Anda akan menggunakan banyak ruang disk jika Anda mengubahnya secara teratur.
Jika Anda hanya berbicara tentang file perpustakaan itu sendiri, ini mungkin OK.
Satu lagi masalah dengan pengaturan ini adalah bahwa iTunes menyimpan databasenya sebagai file biner berpemilik yang git tidak akan dapat melakukan penggabungan (tidak, edit ke iTunes Music Library.xml file tidak akan dibaca kembali oleh iTunes) . Jadi, jika Anda membuat perubahan pada metadata atau menambahkan trek tambahan di kedua mesin, tidak akan ada cara untuk merekonsiliasi perubahan yang dibuat dari kedua ujungnya, Anda akhirnya akan menimpa satu versi database dengan yang lain dan kehilangan data dalam proses .
Masalah ruang disk yang dijelaskan di atas memang benar. Tetapi ada dua masalah yang terpisah. Salah satunya adalah Anda harus menyimpan repositori dan data, sehingga setiap file disimpan 2 kali. Masalah kedua adalah bahwa setiap kali Anda mengubah metadata Anda, salinan musik yang sama sekali baru akan disimpan, jadi lambat laun Anda menyimpan musik Anda sebanyak N kali, di mana N terus meningkat. Masalah pertama mungkin OK, yang kedua adalah hambatan nyata.
Jadi menarik bahwa sementara Git menderita masalah kedua, Subversion tidak. Algoritma diff-nya berfungsi pada file biner, jadi Anda hanya menyimpan perubahan apa. Itu sebabnya saya menggunakan Subversion untuk foto saya, sangat mirip dengan kasing Anda, dan saya sangat senang dengannya.
Berikut ini adalah log yang menggambarkan masalahnya. Perhatikan bahwa Subversion sebenarnya menyimpan tiga salinan: satu di repositori, satu di direktori .svn di copy pekerjaan, dan copy pekerjaan itu sendiri. Namun, itu tidak menggunakan ruang tambahan saat saya mengubah metadata.
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/