Antworten:
Der Hauptnachteil ist der Speicherplatz. Das Repository selbst benötigt den gleichen Speicherplatz wie die "ausgecheckten" Dateien. Dies bedeutet, dass Ihre Sammlung beim Klonen des Repositorys im Grunde doppelt so viel Speicherplatz beansprucht.
Schlimmer noch, selbst wenn Sie Dateien löschen, die Sie nicht mehr möchten, befinden sich weiterhin Kopien in Ihrem Repository, die Speicherplatz beanspruchen.
Möglicherweise möchten Sie sich Synchronisierungstools wie unison ansehen, die für die bidirektionale Synchronisierung von Dateien auf mehreren Computern ausgelegt sind.
Können Sie sich Gründe vorstellen, warum dies eine schlechte Idee wäre?
Git ist für eine solche Verwendung nicht geeignet.
Git funktioniert so, dass die Repository-Daten im .git/Ordner bleiben. Bei Text ist dies kein Problem, es kann leicht komprimiert werden und die Dateien sind klein - das Repository kann ein oder zwei Megabyte groß sein.
Komprimierte Daten (MP3s, JPEGs usw.) können von git nicht weiter komprimiert werden. Da Sie effektiv zwei Kopien der Daten speichern müssen, verdoppelt sich der erforderliche Speicherplatz (eine für die Dateien, eine für das Repository).
Text ist winzig und komprimierbar, und vor allem können Sie leicht zwischen zwei Revisionen "unterscheiden" - nur die Änderungen speichern. Wenn Sie nur eine Zeile ändern, speichert git nur diese eine Zeile (und alle zugehörigen Metadaten wie die Festschreibungsnachricht).
Binärdateien sind schwer zu unterscheiden. Wenn Sie also die Tags für 100 Dateien ändern (z. B. um Grafiken hinzuzufügen oder ein Genre zu ändern), speichert git eine neue Kopie dieser Dateien in seinem .git/Verzeichnis. Angenommen, Sie entfernen dann alle Kommentare aus den Metadaten Ihrer Musik. Git speichert dann eine weitere vollständige Kopie Ihrer Dateien! Dies bedeutet, dass Ihr Repository jetzt mehr als doppelt so groß ist wie Ihre tatsächlichen Dateien (sagen wir, Sie hatten 10 GB Musik, Ihr Musikordner hat jetzt mehr als 30 GB).
Wie gesagt, Git ist für solche Dinge nicht geeignet - es zielt darauf ab, den Quellcode zu verfolgen, mit vielen kleinen Änderungen an Textdateien, nicht an großen Binärdateien. Es macht nicht viel Sinn, einen Revisionsverlauf Ihrer Musikbibliothek zu führen, wenn Sie nur ein Synchronisierungstool benötigen.
Da Sie die Verwendung von git in Betracht ziehen, gehe ich davon aus, dass Sie mit den Befehlszeilentools zufrieden sind. Daher würde ich empfehlen, die Verwendung von rsync zum Synchronisieren Ihrer iTunes-Mediathek zwischen Computern in Betracht zu ziehen. Das größte Problem ist, wie von joshhunt erwähnt, dass iTunes absolute Pfade zu Mediendateien verwendet, sodass die iTunes Library.xmlDatei Dinge wie ... enthält.
<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>
Wenn Sie auf allen Computern dasselbe Betriebssystem und denselben Benutzernamen verwenden, ist dies kein Problem. Behalten Sie die Dateien im selben Pfad und es sollte einwandfrei funktionieren. Wenn nicht, werden die Dinge etwas komplizierter.
Sie können zwei Skripte schreiben, eines, das die Pfade von Maschine A zu Maschine B aktualisiert, und umgekehrt. Sie können Ihre iTunes-Mediathek an einen Ort verschieben /User/Shared/Music/, an dem die Pfade identisch sind (obwohl dies unter OS X -> Windows möglicherweise nicht funktioniert).
Es gibt einige Dienstprogramme zum Synchronisieren von iTunes-Bibliotheken zwischen Computern, z.
(aus diesem Artikel )
Ich bin nicht sicher, ob Git Probleme mit der Größe von Dateien in einer Musikbibliothek hat (es funktioniert nicht gut mit großen Dateien, aber ich bin nicht sicher, wie groß genau), aber Joey Hess hat ein Programm namens git annex für geschrieben Umgang mit dieser Art von Anwendungsfall.
Versionskontrollsysteme sind im Allgemeinen für den Umgang mit Textdateien ausgelegt. Jedes Mal, wenn Sie eine Binärdatei aktualisieren, muss eine völlig neue Datei erstellt werden, anstatt nur ein Delta zu speichern.
Dies bedeutet, dass Ihre Bibliothek viel Speicherplatz beanspruchen würde, wenn Sie sie regelmäßig ändern würden.
Wenn Sie nur über die Bibliotheksdatei selbst sprechen, ist dies möglicherweise in Ordnung.
Ein weiteres Problem bei diesem Setup ist, dass iTunes seine Datenbank als proprietäre Binärdatei speichert, für die git keine Zusammenführung durchführen kann (nein, Änderungen an der Datei iTunes Music Library.xml werden von iTunes nicht zurückgelesen). . Wenn Sie also Änderungen an Metadaten vorgenommen oder zusätzliche Spuren auf beiden Computern hinzugefügt haben, gibt es keine Möglichkeit, die von beiden Seiten vorgenommenen Änderungen in Einklang zu bringen. Am Ende würden Sie eine Version der Datenbank mit der anderen überschreiben und dabei Daten verlieren .
Die oben beschriebenen Speicherplatzprobleme sind sicherlich wahr. Es gibt jedoch zwei getrennte Probleme. Zum einen müssen Sie das Repository und die Daten speichern, damit jede Datei zweimal gespeichert wird. Das zweite Problem ist, dass jedes Mal, wenn Sie Ihre Metadaten ändern, eine ganz neue Kopie der Musik gespeichert wird, sodass Sie Ihre Musik nach und nach N-mal speichern, wobei N kontinuierlich zunimmt. Das erste Problem könnte in Ordnung sein, das zweite ist eine echte Belastung.
Es ist also interessant, dass Git zwar unter dem zweiten Problem leidet, Subversion jedoch nicht. Der Diff-Algorithmus funktioniert für Binärdateien, sodass Sie nur die Änderungen speichern. Deshalb verwende ich Subversion für meine Fotos, die Ihrem Anwendungsfall sehr ähnlich sind, und bin sehr zufrieden damit.
Hier ist ein Protokoll, das das Problem veranschaulicht. Beachten Sie, dass Subversion tatsächlich drei Kopien speichert: eine im Repository, eine in den .svn-Verzeichnissen in der Arbeitskopie und die Arbeitskopie selbst. Es wird jedoch kein zusätzlicher Speicherplatz benötigt, da ich die Metadaten ändere.
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/