I've been considering using Git to manage my iTunes library and allow me to sync it between computers.
Can you think of any reasons why this would be a bad idea?
Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.Sign up to join this community
The main drawback is disk space. The repository itself will take the same amount of space as the set of "checked-out" files. This means when you clone the repository your collection will basically take twice as much disk space.
Worse still, even if you delete files you no longer want, there will still be copies in your repository, taking up space.
You might want to look at synchronisation tools like unison which is designed for two-way synchronisation of files across multiple machines.
Can you think of any reasons why this would be a bad idea?
Git is not suitable to such usage.
The way git works is it keeps the repository data in
.git/ folder. With text, this is a non-issue, it can be compressed easily, and the files are small - the repository might be a megabyte or two.
Compressed data (MP3s, JPEGs etc) cannot be compressed by git further, and since you effectively need to store two copies of the data, this will double the disc-space required (one for the files, one for the repository)
Text is tiny, and compressible, and importantly you can easily "diff" between two revisions - only storing the changes. If you only change one line, git only stores that one line (and any associated metadata, like the commit message)
Binary files are hard to diff, so say you modify the tags on 100 files (say, to add artwork, or change a genre), git will store a new copy of those files in it's
.git/ directory. Say you then strip out all the comments from your music's metadata, git will then store another complete copy of your files! This will mean your repository will now be over twice the size of your actual files (say you had 10GB of music, your music folder will now be over 30GB)
As I said, git isn't suited to such things - it's aimed at tracking source code, with lots of little changes to text files, not big binary files. There's not much point in keeping a revision history of your music library, when all you need a syncing tool.
Since you're considering using git, I assume you're happy enough with command line tools, so I would suggest looking into using rsync to sync your iTunes library between machines. The biggest problem, as joshhunt mentioned, is iTunes uses absolute paths to media files, so the
iTunes Library.xml file contains things like..
If you use the same OS, and same username on all machines, this is a non-issue - keep the files in the same path and it should work fine. If not, things get a bit more complicated..
You could write two scripts, one that updates the paths from machineA to machineB, and vice versa. You could move your iTunes Library to somewhere like
/User/Shared/Music/ so the paths are the same (although this may not work for OS X -> Windows)
There are some utilities to sync iTunes Libraries between machines, such as..
(from this article)
I'm not sure whether Git has problems with the sizes of files in a music library (it doesn't perform well with large files, but I'm not sure exactly how large), but Joey Hess wrote a program called git annex for dealing with this kind of use case.
Version control systems in general are designed for handling text files. Every time you update a binary file it needs to create a completely new file as opposed to just storing a delta.
How this translates to real-world use is that your library would use a lot of disk space if you changed it regularly.
If you are only talking about the library file itself, this might be OK.
One more problem with this setup is that iTunes stores its database as a proprietary binary file which git won't be able to perform merging on (no, edits to the iTunes Music Library.xml file won't be read back in by iTunes). So, if you made changes to metadata or added additional tracks on both machines, there would be no way to reconcile the changes made from both ends, you'd end up overwriting one version of the database with the other and losing data in the process.
You might be thinking of something more along the lines of
The disk space problems described above are certainly true. But there are two separate problems. One is that you have to store the repository and the data, so each file is stored 2 times. The second problem is that every time you change your metadata a whole new copy of the music gets stored, so gradually you end up storing your music N times, where N continually increases. The first problem might be OK, the second is a real drag.
So it's interesting that while Git suffers from the second problem, Subversion doesn't. Its diff algorithm works on binary files, so you only store what changes. That's why I use Subversion for my photos, very similar to your use case, and I'm very happy with it.
Here's a log that illustrates the problem. Note that Subversion actually stores three copies: one in the repository, one in the .svn directories in the working copy, and the working copy itself. However, it doesn't use any extra space as I change the 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/
If I recall correctly, iTunes libraries stores the locations to music as absolute paths, not relative to the library file. This would cause problems if the music was being stored in two different locations on the computers.