Risposte:
Lo svantaggio principale è lo spazio su disco. Il repository stesso occuperà la stessa quantità di spazio dell'insieme di file "estratti". Ciò significa che quando clonerai il repository la tua raccolta richiederà sostanzialmente il doppio dello spazio su disco.
Peggio ancora, anche se elimini i file che non desideri più, ci saranno comunque copie nel tuo repository, occupando spazio.
Potresti voler esaminare strumenti di sincronizzazione come unisono progettato per la sincronizzazione bidirezionale di file su più macchine.
Riesci a pensare a qualche motivo per cui questa sarebbe una cattiva idea?
Git non è adatto a tale utilizzo.
Il modo in cui git funziona è che mantiene i dati del repository nella .git/cartella. Con il testo, questo non è un problema, può essere compresso facilmente e i file sono piccoli: il repository potrebbe essere un megabyte o due.
I dati compressi (MP3, JPEG ecc.) Non possono essere ulteriormente compressi da git e poiché è effettivamente necessario archiviare due copie dei dati, questo raddoppierà lo spazio su disco richiesto (uno per i file, uno per il repository)
Il testo è minuscolo e comprimibile e, soprattutto, puoi facilmente "diff" tra due revisioni, memorizzando solo le modifiche. Se cambi solo una riga, git memorizza solo quella riga (e tutti i metadati associati, come il messaggio di commit)
I file binari sono difficili da diff, quindi supponiamo che modifichi i tag su 100 file (diciamo, per aggiungere elementi grafici o cambiare un genere), git memorizzerà una nuova copia di quei file nella sua .git/directory. Supponi quindi di eliminare tutti i commenti dai metadati della tua musica, git memorizzerà quindi un'altra copia completa dei tuoi file! Ciò significa che il tuo repository ora avrà una dimensione doppia rispetto ai tuoi file effettivi (supponiamo che tu abbia 10 GB di musica, la tua cartella musicale ora sarà più di 30 GB)
Come ho detto, git non è adatto a queste cose: ha lo scopo di tracciare il codice sorgente, con molte piccole modifiche ai file di testo, non ai grandi file binari. Non ha molto senso mantenere una cronologia delle revisioni della tua libreria musicale, quando tutto ciò di cui hai bisogno è uno strumento di sincronizzazione.
Dato che stai pensando di usare git, suppongo che tu sia abbastanza felice con gli strumenti da riga di comando, quindi suggerirei di usare rsync per sincronizzare la tua libreria iTunes tra le macchine. Il problema più grande, come menzionato da joshhunt, è che iTunes utilizza percorsi assoluti per i file multimediali, quindi il iTunes Library.xmlfile contiene cose come ..
<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>
Se usi lo stesso sistema operativo e lo stesso nome utente su tutte le macchine, questo è un problema: mantieni i file nello stesso percorso e dovrebbe funzionare correttamente. In caso contrario, le cose diventano un po 'più complicate ..
È possibile scrivere due script, uno che aggiorna i percorsi da machineA a machineB e viceversa. Puoi spostare la tua libreria di iTunes in un posto simile, /User/Shared/Music/quindi i percorsi sono gli stessi (anche se questo potrebbe non funzionare per OS X -> Windows)
Esistono alcune utilità per sincronizzare le librerie iTunes tra macchine, come ..
(da questo articolo )
I sistemi di controllo della versione in generale sono progettati per la gestione di file di testo. Ogni volta che si aggiorna un file binario, è necessario creare un file completamente nuovo anziché archiviare un delta.
Il modo in cui questo si traduce nell'uso del mondo reale è che la tua libreria userebbe molto spazio su disco se lo cambiassi regolarmente.
Se stai parlando solo del file della libreria stesso, questo potrebbe essere OK.
Un altro problema con questa configurazione è che iTunes memorizza il suo database come file binario proprietario su cui git non sarà in grado di eseguire l'unione (no, le modifiche al file iTunes Music Library.xml non verranno lette da iTunes) . Quindi, se hai apportato modifiche ai metadati o aggiunto tracce aggiuntive su entrambe le macchine, non ci sarebbe modo di conciliare le modifiche apportate da entrambe le estremità, finiresti per sovrascrivere una versione del database con l'altra e perdere i dati nel processo .
I problemi di spazio su disco sopra descritti sono certamente veri. Ma ci sono due problemi separati. Uno è che devi archiviare il repository e i dati, quindi ogni file viene archiviato 2 volte. Il secondo problema è che ogni volta che si modificano i metadati viene memorizzata una copia completamente nuova della musica, quindi gradualmente si finisce per memorizzare la tua musica N volte, dove N aumenta continuamente. Il primo problema potrebbe essere OK, il secondo è una vera resistenza.
Quindi è interessante il fatto che mentre Git soffre del secondo problema, Subversion no. Il suo algoritmo diff funziona su file binari, quindi memorizzi solo ciò che cambia. Ecco perché uso Subversion per le mie foto, molto simile al tuo caso d'uso, e ne sono molto contento.
Ecco un registro che illustra il problema. Si noti che Subversion in realtà memorizza tre copie: una nel repository, una nelle directory .svn nella copia di lavoro e la copia di lavoro stessa. Tuttavia, non utilizzo alcuno spazio aggiuntivo mentre cambio i metadati.
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/