使用Git管理iTunes库？

我一直在考虑使用Git管理iTunes库，并允许我在计算机之间进行同步。

您能想到什么原因导致这个主意不好吗？

主要缺点是磁盘空间。存储库本身将占用与“检出”文件集相同的空间量。这意味着克隆存储库时，您的集合基本上将占用两倍的磁盘空间。

更糟糕的是，即使删除了不再需要的文件，存储库中仍然会有副本，占用了空间。

您可能需要查看诸如统一之类的同步工具，该工具旨在跨多台计算机进行文件的双向同步。

您能想到什么原因导致这个主意不好吗？

Git不适合这种用法。

git的工作方式是将存储库数据保存在.git/文件夹中。对于文本，这不是问题，可以轻松压缩，并且文件很小-存储库可能是一兆字节或两兆字节。

git无法进一步压缩压缩数据（MP3，JPEG等），并且由于您实际上需要存储数据的两个副本，因此这将使所需的磁盘空间增加一倍（一个用于文件，一个用于存储库）

文本很小，并且可压缩，并且重要的是，您可以轻松地“区分”两个修订版本-仅存储更改。如果仅更改一行，则git仅存储该行（以及任何关联的元数据，例如提交消息）

二进制文件很难区分，因此说您修改了100个文件的标签（例如，添加艺术品或更改流派），git会将这些文件的新副本存储在其.git/目录中。假设您随后从音乐的元数据中删除了所有评论，那么git将再存储文件的另一个完整副本！这意味着您的存储库现在将超过实际文件大小的两倍（例如，您有10GB的音乐，您的音乐文件夹现在将超过30GB）

就像我说的那样，git不适合这种情况-它旨在跟踪源代码，对文本文件进行了一些小的更改，而不是大的二进制文件。当您需要同步工具时，保留音乐库的修订历史记录没有多大意义。

由于您正在考虑使用git，因此我假设您对命令行工具很满意，因此建议您考虑使用rsync在计算机之间同步iTunes库。正如joshhunt提到的，最大的问题是iTunes使用媒体文件的绝对路径，因此该iTunes Library.xml文件包含诸如此类的内容。

<key>Location</key>
<string>file://localhost/Users/dbr/Music/iTunes/iTunes%20Music/65daysofstatic/Hole/01%20Hole.mp3</string>

如果在所有计算机上使用相同的操作系统和相同的用户名，则不会出现此问题-将文件放在相同的路径中，应该可以正常工作。如果没有，事情会变得更加复杂。

您可以编写两个脚本，一个用于更新从machineA到machineB的路径，反之亦然。您可以将iTunes资料库移动到类似的位置，/User/Shared/Music/因此路径是相同的（尽管这可能不适用于OS X-> Windows）

有一些实用程序可以在计算机之间同步iTunes库，例如。

• myTuneSync（$ 19.95USD）
• Syncopation（$ 24.95USD）
• SlingShot（29.99美元）

（摘自本文）

我不知道混帐是否有在音乐库文件的大小问题（它不与大文件执行好，但我不知道究竟是如何大），但乔伊赫斯写了一个节目叫混帐附件为处理这种用例。

通常，版本控制系统旨在处理文本文件。每次更新二进制文件时，都需要创建一个全新的文件，而不是仅存储增量文件。

转换为实际使用的方式是，如果定期更改库，则库将使用大量磁盘空间。

如果您仅在谈论库文件本身，则可以。

此设置的另一个问题是iTunes将其数据库存储为专有二进制文件，而git无法对其进行合并（不，对iTunes Music Library.xml文件的编辑不会被iTunes读回） 。因此，如果您在两台计算机上都对元数据进行了更改或添加了其他轨道，则将无法协调从两端进行的更改，最终将用另一版本覆盖数据库的一个版本，并在此过程中丢失数据。

您可能正在考虑更多类似的内容rsync。

上述磁盘空间问题肯定是正确的。但是有两个独立的问题。一种是您必须存储存储库和数据，因此每个文件都存储2次。第二个问题是，每当您更改元数据时，都会存储一个音乐的全新副本，因此逐渐地您最终将音乐存储了N次，其中N不断增加。第一个问题可能是正确的，第二个问题是真正的阻力。

因此，有趣的是，尽管Git遇到了第二个问题，但Subversion却没有。它的差异算法适用于二进制文件，因此您仅存储更改。这就是为什么我将Subversion用于照片的原因，它与您的用例非常相似，对此我感到非常满意。

这是说明问题的日志。请注意，Subversion实际上存储了三个副本：一个存储在存储库中，一个存储在工作副本的.svn目录中，以及工作副本本身。但是，当我更改元数据时，它不会使用任何额外的空间。

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/

如果我没记错的话，iTunes库会将音乐的位置存储为绝对路径，而不是相对于库文件的绝对路径。如果音乐存储在计算机上的两个不同位置，则可能会导致问题。