Verwenden von Git zum Verwalten einer iTunes-Bibliothek?

Der Hauptnachteil ist der Festplattenspeicher. Das Repository selbst beansprucht genauso viel Speicherplatz wie der Satz "ausgecheckter" Dateien. Das bedeutet, dass beim Sammeln des Repositorys Ihre Sammlung im Wesentlichen doppelt so viel Speicherplatz beansprucht.

Noch schlimmer ist, dass selbst wenn Sie Dateien löschen, die Sie nicht mehr benötigen, Kopien in Ihrem Repository vorhanden sind und Platz beanspruchen.

Möglicherweise möchten Sie Synchronisationswerkzeuge wie unison betrachten, die für die bidirektionale Synchronisation von Dateien auf mehreren Computern konzipiert sind.

Fällt Ihnen ein Grund ein, warum dies eine schlechte Idee wäre?

Git ist für eine solche Verwendung nicht geeignet.

Die Funktionsweise von git ist, dass die Repository-Daten im .git/Ordner gespeichert werden . Bei Text ist dies kein Problem, er kann leicht komprimiert werden, und die Dateien sind klein - das Repository kann ein oder zwei Megabytes sein.

Komprimierte Daten (MP3s, JPEGs usw.) können nicht weiter von git komprimiert werden. Da Sie tatsächlich zwei Kopien der Daten speichern müssen, verdoppelt sich dadurch der benötigte 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 werden gespeichert. Wenn Sie nur eine Zeile ändern, speichert git nur diese eine Zeile (und alle zugehörigen Metadaten wie die Festschreibungsnachricht).

Binäre Dateien sind schwer zu unterscheiden. Wenn Sie also die Tags von 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. Sagen Sie, Sie entfernen dann alle Kommentare aus den Metadaten Ihrer Musik, und git speichert dann eine weitere vollständige Kopie Ihrer Dateien! Dies bedeutet, dass Ihr Repository jetzt doppelt so groß ist wie Ihre eigentlichen Dateien (wenn Sie beispielsweise 10 GB Musik hatten, Ihr Musikordner jetzt über 30 GB ist).

Wie gesagt, git ist für solche Dinge nicht geeignet - es dient der Verfolgung von Quellcode mit vielen kleinen Änderungen an Textdateien, nicht an großen Binärdateien. Es macht wenig Sinn, einen Änderungsverlauf Ihrer Musikbibliothek zu speichern, wenn Sie nur ein Synchronisierungswerkzeug benötigen.

Da Sie die Verwendung von git in Betracht ziehen, gehen Sie davon aus, dass Sie mit Befehlszeilentools zufrieden sind. Ich empfehle daher, Rsync zu verwenden, um Ihre iTunes-Mediathek zwischen Computern zu synchronisieren. Das größte Problem, wie bereits erwähnt, ist, dass iTunes absolute Pfade zu Mediendateien verwendet, daher iTunes Library.xmlenthält die Datei Dinge wie ..

<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 funktionieren. Wenn nicht, werden die Dinge etwas komplizierter.

Sie können zwei Skripts schreiben, eines, das die Pfade von Maschine A zu Maschine B und umgekehrt aktualisiert. Sie könnten Ihre iTunes-Bibliothek an einen anderen Ort verschieben, /User/Shared/Music/sodass die Pfade gleich sind (obwohl dies möglicherweise nicht für OS X -> Windows funktioniert).

Es gibt einige Dienstprogramme zum Synchronisieren von iTunes-Bibliotheken zwischen Computern, z. B. ..

• myTuneSync ($ 19.95USD)
• Synkopierung (24,95 USD)
• SlingShot ($ 29.99USD)

(aus diesem Artikel )

Ich bin mir nicht sicher, ob Git Probleme mit der Größe von Dateien in einer Musikbibliothek hat (es funktioniert nicht mit großen Dateien, aber ich weiß nicht genau, wie groß), aber Joey Hess hat ein Programm namens git annex for geschrieben Umgang mit dieser Art von Anwendungsfall.

Versionskontrollsysteme sind im Allgemeinen für die Handhabung von Textdateien ausgelegt. Bei jeder Aktualisierung einer Binärdatei muss eine komplett neue Datei erstellt werden, anstatt nur ein Delta zu speichern.

Dies bedeutet, dass Ihre Bibliothek viel Speicherplatz beansprucht, wenn Sie sie regelmäßig ändern.

Wenn Sie nur über die Bibliotheksdatei sprechen, ist dies möglicherweise in Ordnung.

Ein weiteres Problem bei diesem Setup ist, dass iTunes seine Datenbank als proprietäre Binärdatei speichert, bei der git keine Zusammenführung durchführen kann (Nein, Änderungen an der iTunes Music Library.xml-Datei werden von iTunes nicht wieder eingelesen). . Wenn Sie also Änderungen an Metadaten vorgenommen oder zusätzliche Tracks auf beiden Computern hinzugefügt haben, gibt es keine Möglichkeit, die an beiden Enden vorgenommenen Änderungen abzugleichen. Sie würden am Ende eine Version der Datenbank mit der anderen überschreiben und dabei Daten verlieren .

Sie könnten an etwas mehr denken rsync.

Die oben beschriebenen Speicherplatzprobleme sind sicherlich richtig. Es gibt jedoch zwei getrennte Probleme. Zum einen müssen Sie das Repository und die Daten speichern, sodass jede Datei zweimal gespeichert wird. Das zweite Problem ist, dass jedes Mal, wenn Sie Ihre Metadaten ändern, eine komplett neue Kopie der Musik gespeichert wird. Nach und nach speichern Sie Ihre Musik N-mal, wobei N kontinuierlich zunimmt. Das erste Problem könnte OK sein, das zweite ist ein echter Zug.

Es ist also interessant, dass Git zwar unter dem zweiten Problem leidet, Subversion jedoch nicht. Der Diff-Algorithmus funktioniert für Binärdateien. Sie speichern also nur die Änderungen. Deshalb verwende ich Subversion für meine Fotos, sehr ähnlich zu Ihrem Anwendungsfall, und ich 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, wenn 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/ 

Wenn ich mich richtig erinnere, werden die Speicherorte von iTunes-Bibliotheken als absolute Pfade und nicht relativ zur Bibliotheksdatei gespeichert. Dies würde Probleme verursachen, wenn die Musik an zwei verschiedenen Orten auf den Computern gespeichert wurde.